code review request for suspend/resume deadlock (6876794)

[Daniel D. Daugherty]

Andrew John Hughes wrote:
> 2009/9/21 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>   
>> Andrew John Hughes wrote:
>>     
>>> Assuming your analysis of the locking is correct (it sounds that way
>>> to me), then this seems like a fairly straightforward patch.
>>>       
>> So far no one has found any holes in the logic :-) But then again it
>> took a few years to find this one :-)
>>
>>     
>
> Concurrency problems tend to be like that.  Code like this can be
> difficult to get right, and still far too few people are even taught
> good practice, never mind using it.
>
> MutexLocker seems to make things especially interesting, as there is
> no explicit unlock call, it just happens as a side-effect of the
> instance leaving scope and the destructor being called.
>   

I guess I would argue that there is no explicit lock call either.
That's the beauty of the helper object pattern. You allocate the
helper object for the scope in which you need to hold the lock.
No more. No less. No more forgetting to unlock. No more matching
of lock and unlock calls.

Dan