On 4/14/07, Ivanoff, Alex <[EMAIL PROTECTED]> wrote:
What I call "infinite loop" you call "starvation". So theoretically "arbitrarily many loops before setting succeeds" might become "infinite number of loops before setting succeeds". So why not modify algorithm to try N time to succeed and then throw an exception? Or something else?
Well, you can implement TryPush/Enqueue that does that, but when you really need the call to finish (and succeed) you *have to* let it spin. In practice, it depends on the contention. Lock-free (or wait-free, or non-blocking, or whatever they call them - I call them CAS-based) containers, are *generally* faster than lock-based ones on multiprocessor machines - if spinning wasn't important, than for example, the CRITICAL_SECTION object wouldn't get that (now not so) new function InitializeCriticalSectionAndSpinCount function. We've used successfully both Michael/Scott[1] queues and didn't have a problem with them on Windows, Linux and Solaris, until we ran our app on a 128-cpu Solaris box where the non-blocking one failed (but surely because of our implementation, which although used barriers where needed was missing something somewhere, but we're not Solaris gurus so we just switched to the 2-lock one). One can't just use a lock-free container - he has to understand how it works, and most importantly how it will work on the machine where the app, using the container will run - the point being if don't know what a memory model is, don't use these containers. [1] http://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html Cheers, Stoyan =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
