[llvm] r216338 - Support: add llvm::unique_lock

[Dylan Noblesmith]

On Sat, Aug 23, 2014 at 8:45 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
> On Sat, Aug 23, 2014 at 4:07 PM, Dylan Noblesmith <nobled at dreamwidth.org>
> wrote:
>>
>> Support: add llvm::unique_lock
>>
>> Based on the STL class of the same name, it guards a mutex
>> while also allowing it to be unlocked conditionally before
>> destruction.
>
>
> I didn't notice this in the pre-commit review (the subject didn't really
> make it clear what you were planning on), but why do we need our own? Why
> can't we use std::unique_lock? I'm sure there is some reason, but I'm pretty
> sure it is a bug and not a feature and I'm somewhat opposed to us adding
> this kind of thing just to remove it later rather than fixing the underlying
> problems so that we can use std::unique_lock....
I guess we could, I was hesitant to do that because AFAICS there are
zero in-tree "#include <mutex>" users at all right now, so it'd be the
first and I assumed the status quo was intentional for portability's
sake.

I mean, if we can start using STL threading things now, we could also
completely rip out ScopedLock and MutexGuard in favor of
std::lock_guard. And rewrite llvm_execute_on_thread(). And replace
sys::Mutex with std::recursive_mutex instead.

And is there still a reason to use sys::ThreadLocal<> instead of thread_local?