Linked by Hadrien Grasland on Fri 27th May 2011 11:34 UTC
Permalink for comment 474815
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
More Features »
Sponsored Links



Member since:
2011-05-27
One approach to reduce the amount of semaphores/mutex is to use one thread for each group of resources you may need to lock. Then, as you know that just a single thread modifies that resources, you don't need mutexes. You can adjust the scalability for multiple cores by changing the granularity of the resource groups (smaller groups need more threads).
Each of these threads have a queue of work to be done and you'll have to model your "work" as structs/objects that can be stored in a queue.
So, instead of having:
Component blah:
...do some_stuff with blah;
...wait(lock_for_foobar);
...do X with foobar;
...release(lock_for_foobar);
...do more_stuff with blah;
You will end up with:
Blah.some_stuff:
...do some_stuff with blah;
...enqueue "do X and then notify Blah" to Foobar
Foobar.X:
...do X with foobar;
...enqueue "X done" to Blah
Blah.X_done:
...do more_stuff with blah;
This way you can get rid of mutexes and use only async calls.
Empirically, this approach seems to have larger latency but better throughput. Anybody have seen performance comparisons among these kind of programming models?
Edited 2011-05-27 14:06 UTC