RFR: 8087322: Implement a Semaphore utility class

[David Holmes]

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?

>>>> src/os/windows/vm/os_windows.cpp
>>>> 1905 WindowsSemaphore::~WindowsSemaphore() {
>>>> 1906   if (_semaphore != NULL) {
>>>> 1907     ::CloseHandle(_semaphore);
>>>> 1908   }
>>>>
>>>> I don't think the NULL check is needed here.
>>>
>>> I'll remove it.
>>
>> Not clear to me that we don't need it, and we do perform null checks elsewhere in the windows code.
>
> We already have a NULL check in the constructor, and terminate if that fails.

Yes my mistake.

Thanks,
David