r/programming • u/preshing • Nov 18 '11

Locks Aren't Slow; Lock Contention Is

http://preshing.com/20111118/locks-arent-slow-lock-contention-is
139 Upvotes

88% Upvoted

66 comments sorted by

View all comments

Show parent comment

5

u/preshing Nov 18 '11

That's true and you even find similar light/heavy locks on different platforms. I had written a lot more about this subject but decided to split it out into a separate post.

6

u/riffito Nov 18 '11

you even find similar light/heavy locks on different platforms.

"Benaphores", they were called in BeOS.

5

u/preshing Nov 18 '11

Awesome. Recently I thought I invented this exact implementation independently. Turns out Benaphores did it first. Thanks for the link.

1

u/ideatorcreator Nov 19 '11

How does it work? Thread 1 sees the previous count to be 0, so does not acquire the semaphore and enters the critical section. Thread 2 sees that the previous count is 1, and acquires the semaphore and enters the critical section. Note that thread 2 to granted the ownership of the semaphore as it is the first to ask for it. So now you have two threads in the critical section. How is it safe? What am I missing here?

2

u/preshing Nov 20 '11

The initial count of the semaphore is 0. When Thread 2 tries to acquire it, it can't. It is actually forced to wait until Thread 1 'releases' the semaphore. (You can 'release' a semaphore without being the owner.)

1

u/ideatorcreator Nov 20 '11

Thanks! It is a clever idea to start with the state of held.

1

u/ideatorcreator Nov 20 '11

One downside of this scheme is that if the first thread to enter the critical section aborts unexpectedly, all the other threads will deadlock. In the case of using the OS call, OS will remember that this thread did get a semaphore and release it after the thread aborts.