[cfe-dev] libc++ mutex destructor assertion

[Rui Ueyama]

On Fri, Jun 13, 2014 at 11:21 AM, Zachary Turner <zturner at google.com> wrote:

> I guess ultimately if it's undefined behavior, then we just to make sure
> we don't call exit() under a lock_guard, and perhaps it's better for the
> library to fail violently rather than gracefully so that we're alerted of
> the problems sooner.  So no change to libc++ necessary (if anything, maybe
> make the mutexes assert more consistently.  Currently only recursive_mutex
> asserts, and the others don't).
>

Requesting not to call a function that could call exit() from the code
within lock_guard is too much burden for developers. It'd be similar to a
signal handler from which you can call only very limited set of functions.
If you call a function F from code within lock_guard, you'd need to
guarantee for the future that nobody will never add exit() to F or any
function that could indirectly be called from F. I imagine that's too hard
to guarantee.


> On Fri, Jun 13, 2014 at 11:05 AM, Howard Hinnant <howard.hinnant at gmail.com
> > wrote:
>
>> On Jun 13, 2014, at 1:34 PM, Chandler Carruth <chandlerc at google.com>
>> wrote:
>>
>> >
>> > On Fri, Jun 13, 2014 at 6:32 PM, David Majnemer <
>> david.majnemer at gmail.com> wrote:
>> >> It is very reasonable for this to be UB.  Imagine a mutex where memory
>> is allocated in pthread_mutex_init and free'd in pthread_mutex_destroy.
>>  Unlocks which race with the destruction may end up partying on free'd
>> memory.
>> >>
>> >>
>> >>> It's very easy to support this -- just don't call
>> pthread_mutex_destroy(), the function has no purpose really.
>> >>>
>> >> This is not true. Some implementations, like FreeBSD's libthr, free
>> memory in their pthread_mutex_destroy.  Not calling pthread_mutex_destroy
>> will lead to leaks.
>> >>
>> > This ... makes me extremely sad. It makes mutexes significantly more
>> annoying to use in a bunch of patterns if you cannot destroy them while
>> locked.
>>
>> Fwiw, I once wrote a mutex adaptor/wrapper where in its destructor it
>> locked itself, and then did the necessary de-initialization, then put
>> itself in a “destructed state” and unlocked itself.  When another thread
>> comes along and tries to lock it after destruction, it recognizes the
>> destructed state and throws an exception.  Not 100% bulletproof.  But when
>> the mutex has static storage duration, can be fairly effective.
>>
>> That being said, this particular wrapper would not be useful in Zachary’s
>> example as the lock is leaked by the exiting thread.  However one can dream
>> up all kinds of variations on custom mutexes, and they can all interoperate
>> with std::lock_guard, std::unique_lock, std::condition_variable_any,
>> std::lock, etc.
>>
>> Howard
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140613/76f676c4/attachment.html>