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




Reply via email to