An Oracle blog about Transactional locks

Synchronization horror story of the day

Dave Dice
Senior Research Scientist
While evaluating some new lock algorithms (exposed via LD_PRELOAD interposition on the pthread_lock and condvar interfaces), I noticed that C++ catch and throw on Solaris/SPARC compiled with GCC 4.9.0 will take runtime paths that take locks and impede scaling. Specifically, if you have a set of threads that simply execute "try { throw 20; } catch (int e) {;}", they won't scale as expected because of runtime locks. Unwind_RaiseException and Unwind_Find_FDE always appear on the stack when we encounter the contention. Interestingly, I didn't see any evidence of this behavior on Ubuntu 14.04 on x86.

Join the discussion

Comments ( 6 )
  • guest Thursday, October 9, 2014

    Reminds on the lock in the Hashtable ctor in Java.

  • guest Thursday, October 9, 2014

    there's a global ctor lock for type "Hashtable" ?


  • guest Thursday, October 9, 2014

    Maybe it was a different class but it was appalling to see. It was a commonly used class. I vaguely remember that the ctor of this class required taking some random seed value. This was stored in a static field and required synchronization to take.

    Can't seem to find the source right now. Saw it about one year on Stack Overflow. Maybe it is fixed.

    Maybe it was the default seed initialization in one of the random generators.

  • guest Friday, October 10, 2014

    This might be the dl_iterate_phdr lock used to find the FDE from the eh_frame unwind tables. According to this patch http://marc.info/?l=gcc-patches&m=129102935322345&w=2 if you use the Solaris instead of GNU linker you won't get the binary search eh_frame_hdr table so will end up doing linear searches. There seem to be some other workaround for Solaris ld deficiencies in the unwinding support, so that might be why you aren't seeing this on GNU/x86. Maybe try using GNU ld with GCC on Sparc and see if that reduces the contentions?

  • guest Friday, October 10, 2014

    I took quite a few stack samples and observed synchronization in the dl_ operators, but there also appears to be some locking in Unwind_find_FDE itself. But I think the patch set is relevant to the issue.



  • Luke Thursday, December 3, 2015

    Hi Dave.

    I'm seeing the same scalability bottleneck in manual use of `_Unwind_ForcedUnwind()`. I was looking more carefully at the libunwind implementation (I see the scalability issue in gcc 5.2.0 with glibc 2.19 as well) and see it hitting that `dl_iterate_phdr` lock in addition to some libunwind stuff---memory pools, caching, initialization, etc.

    Before I put too much effort into this I figured I'd check and see if you ever found anything more specific about this issue.



Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.