[LLVMdev] Multi-threading and mutexes in LLVM

[Aaron Ballman]

On Sat, Jun 7, 2014 at 10:16 AM, David Chisnall
<David.Chisnall at cl.cam.ac.uk> wrote:
> On 7 Jun 2014, at 07:50, Chandler Carruth <chandlerc at google.com> wrote:
>
>> I don't see any reason not to reserve a word in the mutex so that in (an ABI-compatible) debug build the mutex can support deadlock detection. Some people are super concerned about having an extra word in a mutex, but I'm not at all.
>
> Making a mutex span multiple cache lines can have very serious and unpredictable performance impacts in the contended case (if you're not contended, a mutex is probably the wrong synchronisation primitive for you) on modern CPUs.

Are we currently bumping up against cache line size limitations with
the libc++ mutex implementation?

>> For libc++, it would probably need to be behind an ABI-breaking macro on Mac and FreeBSD, but we haven't committed to any ABI stability on Linux, so we could probably enable it by default there, and get into build bots.
>>
>> Maybe bring this up on the cfe-dev list to discuss with Marshall and other folks interested in libc++?
>
> On FreeBSD and OS X, the underlying pthread_mutex can already do deadlock detection, so I don't see why you'd need to add another word.  The PTHREAD_MUTEX_ERRORCHECK attribute has been part of POSIX since 1997, so I'd expect it to be supported everywhere.

Not every platform uses pthreads (such as Win32), so presuming that an
underlying library will always support such functionality may not be
the appropriate design decision.

~Aaron