David, thanks for the input, I'll go back to the split versions and update the timing.
/R On Apr 16, 2013, at 1:27 AM, David Holmes wrote: > PS. Also see the existing unpackTime and compute_abstime helper functions for > dealing with pthread/POSIX absolute timed-waits. Better than using > javaTimeMillis() > > David > > On 15/04/2013 10:50 PM, David Holmes wrote: >> 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 >>>>>>>>> ----- >>>>>>>> >>>>>> >>>>> >>>