RFR: 8011882: Replace spin loops as back off when suspending

[David Holmes]

On 15/04/2013 10:07 PM, Rickard Bäckman wrote:
> David,
>
> this is what the suggested semaphore.cpp/semaphore.hpp. Is that what you are looking for?

<sigh> I thought so till I saw it - far uglier and complicated than I 
had hoped. Sadly the three separate versions wins for me.

By the way you can't do this:

  116 bool Semaphore::timedwait(unsigned int sec, int nsec) {
  117   struct timespec ts;
  118   jlong endtime = os::javaTimeNanos() + (sec * NANOSECS_PER_SEC) + 
nsec;
  119   ts.tv_sec = endtime / NANOSECS_PER_SEC;
  120   ts.tv_nsec = endtime % NANOSECS_PER_SEC;

javaTimeNanos is not wall-clock time, but the POSIX sem_timewait 
requires an absolute time - you need to use javaTimeMillis(). Which also 
means the wait will be affected by changes to wall-clock time.

David
-----

> Webrev: http://cr.openjdk.java.net/~rbackman/webrev/
>
> Thanks
> /R
>
> On Apr 15, 2013, at 8:59 AM, David Holmes wrote:
>
>> On 15/04/2013 4:55 PM, Rickard Bäckman wrote:
>>> David,
>>>
>>> any new thoughts?
>>
>> Not a new one but I think factoring into Semaphore.hpp/cpp and using a few ifdefs is better than three versions of the Semaphore class. The signal thread could use it also.
>>
>> David
>>
>>> Thanks
>>> /R
>>>
>>> On Apr 12, 2013, at 8:06 AM, Rickard Bäckman wrote:
>>>
>>>>
>>>> On Apr 12, 2013, at 7:34 AM, David Holmes wrote:
>>>>
>>>>> On 12/04/2013 3:01 PM, Rickard Bäckman wrote:
>>>>>>
>>>>>> On Apr 12, 2013, at 1:04 AM, David Holmes wrote:
>>>>>>
>>>>>>> On 11/04/2013 11:02 PM, Rickard Bäckman wrote:
>>>>>>>> On Apr 11, 2013, at 2:39 PM, David Holmes wrote:
>>>>>>>>> So what did you mean about pthread_semaphore (what is that anyway?) ??
>>>>>>>>
>>>>>>>> Never mind, pthread condition variables.
>>>>>>>
>>>>>>> Ah I see.
>>>>>>>
>>>>>>>>>
>>>>>>>>> I really, really, really don't like seeing three versions of this class :( Can't BSD and Linux at least share a POSIX version? (And I wonder if we can actually mix-n-match UI threads on Solaris with POSIX semaphores on Solaris?)
>>>>>>>>
>>>>>>>> I don't like it either, our OS code isn't really helpful when it comes do reusing things :) Not sure how I would layout things to make them only available on BSD (Not Mac) and Linux. I guess os_posix.hpp with lots of #ifdefs, but I'm not sure I"m feeling that happy about that.
>>>>>>>
>>>>>>> Why would the os_posix version need a lot of ifdefs?
>>>>>>
>>>>>> Well, I guess we would need:
>>>>>>
>>>>>> (in ifdef pseudo language)
>>>>>>
>>>>>> #ifdef (LINUX || (BSD && !APPLE))
>>>>>> …
>>>>>> #endif
>>>>>
>>>>> But if it isn't "posix" then we won't be building os_posix - right?
>>>>
>>>> Linux, Solaris, Bsd & Mac builds and include os_posix. They are all "implementing posix" we are just not using the same semaphore implementation on all of them.
>>>>
>>>>>
>>>>>> The second interesting problem this will get us into is that sem_t is not declared in this context. Where do we put the #include <semaphore.h>? Impossible in os_posix.hpp since it is included in the middle of a class definition. I could put it in os.hpp in the #ifdef path that does the jvm_platform.h includes, not sure if that is very pretty either.
>>>>>
>>>>> Semaphores are already used by the signal handler thread - semaphore.h is included in os_linux.cpp etc, so why would os_posix be any different ?
>>>>>
>>>>> But couldn't we just have a Semaphore.h/cpp with any needed ifdefs?
>>>>>
>>>>>>> Do we really have four versions:
>>>>>>> - linux (posix)
>>>>>>> - BSD (posix)
>>>>>>> - Solaris
>>>>>>> - Mac (different to BSD?)
>>>>>>>
>>>>>>
>>>>>> 3:
>>>>>> 1) linux & bsd uses the sem_ interface
>>>>>> 2) solaris uses the sema_ interface
>>>>>> 3) mac uses the semaphore_ interface
>>>>>
>>>>> Okay but if mac is BSD why can't we use bsd ie posix interface instead of the mach semaphore_ ?
>>>>
>>>> Because apple decided not to implement sem_timedwait.
>>>> On Solaris we use sema_ because sem_ requires us to link with -lrt which we currently don't (and I'm not really feeling like adding it)
>>>>
>>>>>
>>>>>
>>>>> BTW I like the idea of using the semaphore, we're just haggling on the details. ;-)
>>>>
>>>> I'm fine with that :)
>>>>
>>>> /R
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> /R
>>>>>>
>>>>>>> ??
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>
>>>>
>>>
>