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

Rickard Bäckman rickard.backman at oracle.com
Thu Apr 11 06:02:48 PDT 2013


On Apr 11, 2013, at 2:39 PM, David Holmes wrote:

> On 11/04/2013 10:30 PM, Rickard Bäckman wrote:
>> David,
>> 
>> On Apr 11, 2013, at 2:15 PM, David Holmes wrote:
>> 
>>> Rickard,
>>> On 11/04/2013 9:51 PM, Rickard Bäckman wrote:
>>>> Hi all,
>>>> 
>>>> can I please have reviews for this change.
>>>> 
>>>> In the current implementation do_suspend uses spin loops to wait until a thread has been suspended. I would like to change that to use semaphores to reduce CPU usage and also make it easier to have a deterministic timeout. Since we are posting to the semaphore in the signal handler we can't use pthread_semaphore since it isn't async safe, which is why all implementations uses low-level os-specific semaphore constructs.
>>> 
>>> POSIX Semaphore sem_post() is async-signal safe:
>> 
>> Yes, and they are used in the implementation on Linux and BSD. Solaris uses the sema_{post,wait,…} (since that was we were already using for other things) and on Mac we use semaphore_{signal, wait, …}
> 
> So what did you mean about pthread_semaphore (what is that anyway?) ??

Never mind, pthread condition variables. 

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

/R

> 
> David
> 
>> /R
>> 
>>> 
>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04
>>> 
>>> David
>>> -----
>>> 
>>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8011882
>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8011882/
>>>> 
>>>> Thanks
>>>> /R
>>>> 
>> 



More information about the serviceability-dev mailing list