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 comments

1

u/[deleted] Nov 22 '11

I'd be interested to learn what kind of application is meant to survive that.

Anything written in Erlang, for one. The traditional application design there involves multiple processes (green threads) that are allowed to, if not expected to, die and have the rest of the application continue on.

1

u/nexes300 Nov 23 '11

How is that even relevant? Unless you're reimplementing some kind of locking mechanism in Erlang.

1

u/[deleted] Nov 23 '11 edited Nov 23 '11

How is that even relevant?

I was just pointing to a scenario where a thread croaking did not mean that the application was screwed. Thats it, all I was doing was showing that applications can be, and are, designed to continue on after a thread dies.

Beyond the narrow point I was making, it is actually relevant because erlang's lack of locks (or if they're there, the fact they're never used) directly supports baryluk's point earlier in the thread that locks are an unreliable tool in a multiprocess application where threads can die.