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

[David Blaikie]

I seem to recall Zach might have come across some reason we couldn't use
the standard library primitives here...?
On Aug 23, 2014 9:59 PM, "Dylan Noblesmith" <nobled at dreamwidth.org> wrote:

> 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?
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140824/7ffd98c3/attachment.html>