[LLVMdev] Multi-threading and mutexes in LLVM

[Kostya Serebryany]

On Sat, Jun 7, 2014 at 10:50 AM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Fri, Jun 6, 2014 at 10:57 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>> As for the deadlocks, indeed it is possible to add deadlock detection
>> directly to std::mutex and std::spinlock code.
>> It may even end up being more efficient than a standalone deadlock
>> detector --
>> but only if we can add an extra word to the mutex/spinlock object.
>> The deadlock detector's overhead comes primarily from two tasks:
>>   1. get the metadata for the lock in question.
>>   2. query the lock-acquisition-order graph to see if there is a loop.
>>
>> If the lock-acquisition-order graph is sparse (99% of cases we've seen),
>> then the task #1 may constitute  up to 50% of the overhead.
>> If we can add a word to std::mutex/std::spinlock data structures then the
>> task #1 becomes trivial.
>>
>
> 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.
>
> 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++?
>

Yes. I still have a debt with by vector annotations in libc++, let me deal
with that first and then send a proposal about deadlock detector.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140609/ea8a3d55/attachment.html>