SainTiss <[EMAIL PROTECTED]> writes: > Just a quick note to indicate that, personally, I'd be most interested in the > multithreading part.
Okay... if you download the patches, have a look in function/examples/threading. BTW, are you a Windows or a Pthreads user? > Actually, is the strategy you're pursueing atm a well-known one? Or did you > come up with it yourself for the particular COLA object model? For now, I'm using much the same strategy that .NET uses: one lock installed in each object for applications to use. However, COLA allows me to pay for this overhead only if the application explicitly asks for threading. After I implemented the (beginnings of the) object tracing facility used to allocate the locks, I read that that's the way that some Smalltalks (but not Squeak) do #become:. I chose read-write locks because they can give better performance at the cost of 25% more memory per lock (8 words as opposed to 6 for mutexes on i386/Linux Pthreads). My eventual goal is a drop-in, pay-as-you-go software transactional memory, but locking is easier initially. -- Michael FIG <[EMAIL PROTECTED]> //\ http://michael.fig.org/ \// _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
