[libcxx-dev] std::unique_lock with thread annotations

[Pooyan McSporran via libcxx-dev]

Ok, thanks for that, sounds like it's as I'd guessed.  I'll just use
lock_guard instead of unique_lock.

Thanks!

On Sat, 12 Oct 2019 at 13:49, Eric Fiselier <eric at efcs.ca> wrote:

> Last time I looked the attributes weren't expressive enough to model
> unique_lock.
> I don't believe there's any work on going to improve this.
>
> I'll happily annotate `unique_lock` when Clang can model it.
>
>
> On Fri, Oct 11, 2019, 9:51 PM Pooyan McSporran via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I've been experimenting with -Wthread-safety in clang/libc++.  The
>> documentation at https://libcxx.llvm.org/docs/UsingLibcxx.html says that
>> _LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS is 'used to enable -Wthread-safety
>> annotations on libc++’s std::mutex and std::lock_guard'.
>>
>> I'm hoping to use thread-safety analysis for a sizeable code base which
>> makes a lot of use of unique_lock, but there's no libc++ annotations for
>> unique_lock, just for lock_guard.  What is the status of this?  Is this
>> something that might be addressed in the future, or is it fundamentally
>> problematic?  I gather it's complicated by the optional deferred locking
>> semantics.
>>
>> For my purposes I can work around the issue by changing uses of
>> unique_lock to instead be lock_guard (which needs to be done anyway) so
>> it's not a show-stopper for me, just curious.
>>
>> Thanks!
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20191012/6008bc11/attachment-0001.html>