RFR: 8087322: Implement a Semaphore utility class

David Holmes david.holmes at oracle.com
Wed Jun 24 23:32:24 UTC 2015

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:


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.


More information about the hotspot-dev mailing list