Comments on: Lock Freedom is overrated (sometimes)

By: Tomer Gabel

Tomer Gabel — Wed, 28 Jul 2010 22:18:49 +0000

Concurrency 101: think before you do. This applies to correct data structure choices as much as it does concurrency/synchronization layout, trading safety and simplicity for performance and complexity.

In simpler terms: don’t do anything I wouldn’t do… 🙂

By: Oren Ellenbogen

Oren Ellenbogen — Sat, 24 Jul 2010 10:45:07 +0000

looks like after you edited the post my comment became obsolete.. 🙂

By: ripper234

ripper234 — Sat, 24 Jul 2010 08:35:00 +0000

This is exactly my point.

The map is the global object, so it deserves special attention. I would start with a concurrent hashmap for its implementation. Another option is to have several (say 100) maps, each with its own lock – so the contention for each lock is much smaller (you can calculate which map holds which inbox by hashing its ID).

An individual inbox, however, will get almost zero contention – so its implementation can be very naive. The gist here is to think carefully about how much contention each data structure will see, and choose its implementation accordingly.

By: Oren Ellenbogen

Oren Ellenbogen — Sat, 24 Jul 2010 08:28:15 +0000

I might be missing something, but you’re performance profiling looks a bit off.
It seems that you’ll always need to call the map (MANY MANY times) to in order to do any operation. It doesn’t really matter if the value of the map is not used that often (thus it might be okay to lock the inbox object), it’s the map that you’re trying to avoid contention on.