English | 中文 | Русский | Français

2,598 Posts served

8,346 Conversations started

Locks Are Bad!!!

By Asaf Shelly (16 posts) on March 24, 2009 at 9:32 am

Students are tought to use Locks such as MUTEXs and Critical Sections. We are also told that a MUTEX is a type of Semaphore. This is all very bad!

When we lock we practically try to make sure that the resource is locked to a single core. - We have a multicore CPU but we try to make sure that all work with a resource is done using only one core. Why?

Even if we ensure that our code is using locks correctly and we are blocking our application successfully, there is still the possibility for a Race-Condition. How? - simple: Locks are only flags. Nothing more. At any given time someone can freely access our 'locked' object.

We are told that we are locking for a code section: "Critical Section" is the name, but we are not. We are locking for a resource. It is so simple to avoid Deadlocks when we understand that it is resource-ownership that we are looking for.

... and no, a MUTEX is not a Semaphore of one. The system can clean up a MUTEX if a thread terminates or unexpectedly exits. A MUTEX can also be re-entrant (system / library dependant)

If you find yourselves using locks when you are not a very low level infrastructure designer (such as designing a type of queue) then you have something very wrong going on.

If you find yourself using a lock that was not specifically part of the system design then something is really very very wrong with the system. Programmers have absolutly no reason for declaring new lock objects.

Don't use locks unless you really really have to because locks are bad!

Categories: Parallel Programming, Software Engineering

Comments (10)

March 24, 2009 11:39 AM PDT Ed Goward

Sounds like the voice of experience... Very recent, bad experience. Thanks for passing it on.

March 24, 2009 2:51 PM PDT ran6110

I've always found that with a little thought and code manipulation I can remove all locking entities. They just seem like a cheesy way around process control.

March 24, 2009 11:09 PM PDT Asaf Shelly Total Points: 1,430 Status Points: 930 Brown Belt

I completely agree. This is why the multi-threaded version of STL is slower than the single-threaded version. Most times multi-threaded implementations were trying to defend from multi-threading, not take advantage of the power in parallel work. They should have called it a de-multi-threaded implementation.

March 25, 2009 9:29 AM PDT vlion

You're not convincing. Saying "locks are bad" and leaving it there is really pointless. Why are locks bad? What research backs it up? Why are locks used, if they are so bad? Very bad article. If I had to grade it, I'd give it an F and require a rewrite.

March 25, 2009 10:35 AM PDT Clay Breshears (Intel) Total Points: 15,225 Status Points: 15,225 Black Belt

"At any given time someone can freely access our 'locked' object." There are no evil threads, just threads programmed for evil. Don't program threads for evil. :-)

March 25, 2009 2:05 PM PDT Asaf Shelly Total Points: 1,430 Status Points: 930 Brown Belt

Hi vlion.. Locks are bad because: int Func() { LockBufferMUTEX( ) Buffer [ 23 ] = 'A'; UnlockBufferMUTEX( ) } will store 'A' to Buffer[23] most of the times. Some times it will store something else because of a race condition. This actually happens when someone in professional services has to release a version for a customer and does not have time to go over the design documentation to verify lock - resource correlations. This can also happen when more than one lock is used and the code was copy-pasted into a new function which was then edited to omit some parts. Especially if a single lock was used for more than one resource. ... Threads are programmed like outlaws: not bad, just uneducated :-)

March 25, 2009 2:51 PM PDT Gastón C. Hillar Total Points: 3,181 Status Points: 3,181 Black Belt

Hi Asaf, My opinion is the following. If you can parallelize an algorithm using independent threads and you can avoid locks, using a very efficient design, then do it. I have no doubts that avoiding locks is the best way to achieve the best performance and the easier to understand code. I've found many applications in which you can parallelize algorithms without using locks. However, it is true that many advanced algorithms require locks. The problem is that many developers are using out-of-date tools to create applications optimized for multicore. They offer worst performance than single-threaded apps. Cheers, Gastón

March 26, 2009 9:47 AM PDT Asaf Shelly Total Points: 1,430 Status Points: 930 Brown Belt

Hi Gastón, As always I agree with most :-) I would say that the problem today is not old tools, it is old methodologies and old design patterns. OOP does not give you the reason to use GOTOs so we don't. OOP however makes it too easy to write untraceable code.... but don't get me started on OO :-) http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-ob.....-modeling/

March 27, 2009 11:00 AM PDT vlion

So, if I take your meaning right, bad locking code is bad code, which is bad? But you *aren't* addressing code which is written well, just code that is bad(which happens to have locks). That is a logical fallacy.

March 31, 2009 5:34 PM PDT Asaf Shelly Total Points: 1,430 Status Points: 930 Brown Belt

I would put it as: Code that requires locks which are not part of the system design is bad code with bad design. Locks are like GOTOs for C\++. If you can't manage them effectively then you are in a great problem. Forget about locks. They are like traffic lights - only one has a green light at a time. You can only use your resource on one core at a time. Use a street square and allow everyone to move freely. Split your resource into smaller parts - one for each core. Asaf

Trackbacks (0)

Leave a comment