RFR: 8087322: Implement a Semaphore utility class

Dean Long dean.long at oracle.com
Wed Jun 24 23:49:23 UTC 2015


On 6/24/2015 4:32 PM, David Holmes wrote:
> On 25/06/2015 9:07 AM, Kim Barrett wrote:
>> On Jun 24, 2015, at 6:39 PM, David Holmes <david.holmes at oracle.com> 
>> wrote:
>>>
>>>>> sem_trywait can also fail with EINTR.
>>>>
>>>> Will fix the assert.
>>>
>>> trywait can't fail with EINTR as it does not block - so nothing can 
>>> be interrupted.
>>
>> When dealing with standards like POSIX, I generally try to listen as
>> closely as I can to what the standard says, rather than trusting my
>> intuition about how something "ought" to work.  Compiler and library
>> authors are known for driving trucks through holes in one's intuition,
>> and then saying nyah, nyah to complaints.
>>
>> So when POSIX says sem_trywait can return an error of EINTR and my
>> intuition says "no way", *I* still include the check. YMMV.
>
> <sigh> The POSIX spec is somewhat inconsistent on the matter:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_trywait.html 
>
>
> It states explicitly:
>
> "The sem_wait() function is interruptible by the delivery of a signal."
>
> Nothing about trywait - which makes sense as trywait never actually 
> waits - but also says in the ERRORS section that trywait may fail if 
> interrupted by a signal.
>
> So yes we should check for EINTR on the trywait - and retry I guess?

Retry doesn't sound necessary for trywait, and an unbounded number of 
retries sounds bad.  I would think one attempt is enough.

dl


More information about the hotspot-dev mailing list