Hi Hans, SainTiss <[EMAIL PROTECTED]> writes:
>> Okay... if you download the patches, have a look in >> function/examples/threading. > Ok, I will have a look, and let you know if I get it running. That'd be great! I still have to implement the code that actually allocates and uses the locks, which is a fairly major showstopper, but you can at least see a stupid test in which I add a method to a vtable while another thread is using it. If you come up with any test cases, that would be great. I need ways of stressing the system to help give confidence to the lock-free vtables and the metaobject locking mechanism as well. >> BTW, are you a Windows or a Pthreads user? > I'm a pthreads user; does that make a difference in usage? It does't have any Windows support yet (still haven't bothered to get COLA working on my Windows XP box), so you're in luck. >> 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 was wrong. It turns out Squeak *does* use their object-trace facility, but they changed the interface to #become: to improve performance so that all the objects of a class could be replaced with a single method call. >> 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. > > Ok, sounds cool. was there an intuitivity argument involved as well? Well, kinda, if you consider my own intuition to be an "intuitivity argument". ;) Seriously, though... I expect that COLA will have to support many different threading models, and probably simultaneously too. So, I'm just trying to guess what fundamental features applications are going to need. After that, I hope that peer review and real applications will determine the direction of growth. Thanks, -- Michael FIG <[EMAIL PROTECTED]> //\ http://michael.fig.org/ \// _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
