[quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.20ecbc3a425209b028b@msnews.microsoft.com...
> Shawn B. <leabre@html.com> wrote:
>> Why is lock-free programming more efficient than using monitors or mutex?
>> What is it that makes lock-free programming more efficient? I'm having a
>> hard time comprehending this.
If you organized lock-based programming the same way as lock-free, you would
see almost as big a performance improvement. However, locks are often too
broad -- taken too often and held too long. Lock-free programming always
prepares a result, unsynchronized, then does a test-and-set to commit the
result if the input didn't change.
[quoted text, click to view] >
> 1) Lock-free code never has to wait for another thread to finish before
> continuing
That's not precisely true. There's almost always a loop on test-and-set,
and you can't leave that loop until you get access to the shared resource.
The time for potential collision and retry is very slim though.
[quoted text, click to view] > 2) The very act of acquiring and releasing a lock is "costly" (not
> very, but it's not free either)
>
> I personally don't attempt lock-free programming in general - I'll very
> occasionally use a volatile variable or Interlocked.Increment, but
> that's about it. For anything else I use locks.
>
> --
> Jon Skeet - <skeet@pobox.com>
>
http://www.pobox.com/~skeet Blog:
http://www.msmvps.com/jon.skeet > If replying to the group, please do not mail me too
[quoted text, click to view] "Günter Prossliner" <g.prossliner/gmx/at> wrote in message
news:uIT7V5NuHHA.4788@TK2MSFTNGP05.phx.gbl...
> Hello Shawn!
>
>> Why is lock-free programming more efficient than using monitors or
>> mutex? What is it that makes lock-free programming more efficient?
>
> There are mainly two factors involved here:
>
> 1. When you use locking, threads of your application will wait to acquire
> the lock instead of doing something usefull
>
> 2. There is an overhead involved when you use the various synronization
> objects. Of cause the use of the Interlocked... Functions (which are
> needed for lock-free programming), also have some overhead, but less than
> the traditional syncronization objects.
>
> But remember: Producing code for multithreaded environments is not easy.
> Producing lock-free code is even much more complicated and time-consuming.
> So in my opinion lock-free coding should not replace traditional
> syncronization methods. It shall be used in VERY critical methods /
> classes
Sure it should -- as well-tested reusable code written by an expert. SList
is an example of this. Lock-free containers can be just as easy to use as a
simple container in single threaded code, but with the added thread safety
for a low cost.
[quoted text, click to view] > where performance absolutly nessersary, and locking has been identified as
> the bottleneck.
Actually, locking is harder to get right than using a prebuilt thread-safe
object, which is what lock-free programming usually boils down to. In any
case, the amount of actual volatile code should be kept very small to ease
reasoning about the system. And due to the lower cost of lock-free, it's
reasonable to use it a lot more extensively than locks.
[quoted text, click to view] "Shawn B." <leabre@html.com> wrote in message
news:%23VZyedNuHHA.4972@TK2MSFTNGP05.phx.gbl...
> Greetings,
>
> Why is lock-free programming more efficient than using monitors or mutex?
> What is it that makes lock-free programming more efficient? I'm having a
> hard time comprehending this.
Simply put, the locking primitive can't be implemented with a lock. (More
advanced locks can be created with simpler locks). So every lock has at
least two operations implemented with lock-free threadsafe programming --
acquiring ownership of the lock, and releasing the lock. Right there, it's
already twice as expensive as a lock-free operation.
[quoted text, click to view] Ben Voigt [C++ MVP] <rbv@nospam.nospam> wrote:
> >> Why is lock-free programming more efficient than using monitors or mutex?
> >> What is it that makes lock-free programming more efficient? I'm having a
> >> hard time comprehending this.
>
> If you organized lock-based programming the same way as lock-free, you would
> see almost as big a performance improvement. However, locks are often too
> broad -- taken too often and held too long. Lock-free programming always
> prepares a result, unsynchronized, then does a test-and-set to commit the
> result if the input didn't change.
Yes - you often see people who are reasonably new to threading who
think that by taking locks out all the time you end up with thread-safe
code. In fact you end up with deadlocks, and when you don't have
deadlocks you have poor performance :(
Not only does reducing lock spans obviously reduce the amount of
waiting for locks to become available, but I believe that taking an
uncontested lock takes significantly more cycles than taking a lock
which is initially contested.
[quoted text, click to view] > > 1) Lock-free code never has to wait for another thread to finish before
> > continuing
>
> That's not precisely true. There's almost always a loop on test-and-set,
> and you can't leave that loop until you get access to the shared resource.
> The time for potential collision and retry is very slim though.
Yes, true enough.
--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog:
http://www.msmvps.com/jon.skeet
