RFR: 8087322: Implement a Semaphore utility class (original) (raw)

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:

semtrywait 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 semtrywait can return an error of EINTR and my intuition says "no way", I still include the check. YMMV.

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/oswindows.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

More information about the hotspot-dev mailing list