<div dir="ltr">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).</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 13, 2014 at 11:05 AM, Howard Hinnant <span dir="ltr"><<a href="mailto:howard.hinnant@gmail.com" target="_blank">howard.hinnant@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Jun 13, 2014, at 1:34 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>

<br>
><br>
> On Fri, Jun 13, 2014 at 6:32 PM, David Majnemer <<a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a>> wrote:<br>
>> 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.<br>

>><br>
>><br>
>>> It's very easy to support this -- just don't call pthread_mutex_destroy(), the function has no purpose really.<br>
>>><br>
>> 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.<br>
>><br>
> 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.<br>
<br>
</div></div>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.<br>

<br>
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.<br>

<span class="HOEnZb"><font color="#888888"><br>
Howard<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>