RFR: 8087322: Implement a Semaphore utility class

[Stefan Karlsson]

Hi again,

Here's a version that gets rid of the max parameter:
  http://cr.openjdk.java.net/~stefank/8087322/webrev.02.delta
  http://cr.openjdk.java.net/~stefank/8087322/webrev.02

The patch also contains a few minor cleanups and removes the redundant 
BsdSemaphore::trywait(), which is already defined in PosixSemaphore.

Thanks,
StefanK

On 2015-06-15 22:28, Stefan Karlsson wrote:
> Hi again,
>
> I've hopefully addressed some of Kim's and David's concerns with the 
> following version:
>
> http://cr.openjdk.java.net/~stefank/8087322/webrev.01.delta/
> http://cr.openjdk.java.net/~stefank/8087322/webrev.01/
>
> Changes in the current version of the patch:
>
> - Created a POSIX version that is used by Linux and Solaris (and maybe 
> AIX?).
>
> - Use asserts instead of guarantees. (I've got offline feedback that 
> others preferred at least some of the guarantees.)
>
> - Print the errno value and the errno string in the posix version
>
> - Removed trywait and timedwait from the Semaphore class and added 
> that functionality in platform-specific semaphore classes. This gets 
> rid of the Unimplemented() functions in os_windows.cpp.
>
> - I removed the IMPLEMENTS_SEMAPHORE_CLASS define.
>
> Some comments about the current patch:
>
> - I have not removed the 'max' parameter, since I haven't yet figured 
> out what the max value should be used for windows.
>
> - OS X doesn't implement unamed POSIX semaphores, so I have to go 
> through hoops to compile out the POXIS version when building on OS X.
>
> - I had to add -lrt to get the patch to link on Solaris.
>
> Tested with JPRT,
>
> Thanks,
> StefanK
>
> On 2015-06-12 17:21, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to create a Semaphore utility class. I need 
>> this class to implementing faster GC thread synchronization [1].
>>
>> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8087322
>>
>> Some of our platforms already implement a Semaphore class, but those 
>> classes are hidden inside os_<os>.cpp. I've moved the class 
>> declaration to semaphore.hpp, but the implementation is left in the 
>> os_<os>.hpp. I considered creating semaphore_<os>.cpp files, but I 
>> ended up having to restructure too much code and I wanted to focus on 
>> the feature in [1] instead. Should I create a RFE to move the 
>> semaphore implementations?
>>
>> There seems to be another opportunity to cleanup the code. If we take 
>> os_linux.cpp, as an example, the code uses both the existing 
>> Semaphore class and the global ::sem_wait and ::sem_post functions. 
>> We might want to consider unifying that code.
>>
>> Since HotSpot is built on platforms that I don't have access to and 
>> can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, 
>> that I can detect if the the current platform implements the 
>> Semaphore class, and choose what synchronization primitive to use by 
>> the GC.
>>
>> The os_bsd.cpp file has support for "non-apple BSD", but I've only 
>> tested this patch with OS X.
>>
>> This patch has been tested in JPRT and our nightly testing together 
>> with the patches in [1]. The patch also contains a few unit tests in 
>> semaphore.cpp.
>>
>> Thanks,
>> StefanK
>>
>> [1] 
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html
>