Hi all, Apologies for commenting before understanding Capability.c very well. But it seems that this file uses locking quite heavily. Has there been an analysis of whether atomic memory ops and lock free algorithms could play any role here?
Simon mentioned keeping track of the number of items in the queue so as not to have to traverse it while holding the lock. That, for example, seems that it could be accomplished with an atomically modified counter. Cheers, -Ryan On Wed, Nov 17, 2010 at 10:25 AM, Edward Z. Yang <ezy...@mit.edu> wrote: > Excerpts from Simon Marlow's message of Wed Nov 17 06:15:46 -0500 2010: > > I suggest keeping track of the number of items in the queue. > > Ok, I added a spare_workers_no field to the Capability struct. > > > So I think the main thing missing is a call to workerTaskStop(). > > Added. > > > It would be really nice if we could arrange that in the case where we > > have too many spare workers, the extra workers exit via the same route, > > but I suspect that might not be easy. > > Do you mean, spare workers that have useful tasks to do? > > Edward > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users