This is the mail archive of the java-discuss@sources.redhat.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Segment Register thread descriptor (was Re: Jv_AllocBytesChec ked)


[Ulrich wrote:]
> Tom Tromey <tromey@redhat.com> writes:
> 
> > It looks like at least some of the atomicity.h files come 
> from glibc.
> 
> This interface is not adequate.  There is in fact no generally usable
> interface I know of.
Agreed.  Unfortunately.

> Don't start thinking about something like this
> before you have looked at all the existing architectures and read some
> research papers about what we can expand in the near future.
> 
I think I qualify on most of those counts.  Here's an attempt at describing
what I would minimally want to see in such a header file:

1) A type definition for an integral "thread id" type.

2) An inline function for retrieving such a thread id as fast as possible.
The only property of this id is that I always get the same answer from the
same thread, and that no two concurrently running threads may return the
same id.  (In practice, I'm likely to get a pointer to some thread
descriptor, but I'm certainly not allowed to dereference it.)

3) Some collection of atomic update primitives.  I could live with
compare-and-swap as the only one.  There's a performance advantage to be
gained from providing more, but it's much smaller than the difference
between compare-and-swap and explicit locking.  (My next priority would be
to export a simpler test-and-set facility, which is sometimes available on
architectures that don't directly provide compare-and-swap.  The next
priority would be atomic fetch and add, which is needed for reference
counts, but can be emulated with compare-and-swap.) These should have the
following properties:
	- There should be variants for at least int and long.
	- There should be variants that add different memory barrier
properties.  The ones
	  I've found useful for compare-and-swap are:
		- none
		- acquire (later memory operations cannot move forward)
		- release (earlier memory operations cannot move backwards
past the atomic op.)
        (Perhaps a full barrier should be another option, since I believe
that's what you
	  get on most platforms.)
	- They have a lock parameter, of a type declared in the header file.
This parameter
	  is unused if the hardware provides the operation.  If the hardware
fails to provide
	  the operation, the call attempts to acquire the lock for the
duration of the operation.
	  (This lock would usually be something like a test and set
location, not a full pthreads
	  lock.  Compare-and-swap fails if the lock is held by another
thread.  It does not block.)
	  (I believe I saw something like this in linuxthreads, though I
didn' locate it right
	  now.)

4) Suitable macro definitions to allow locks for atomic operations to be
introduced and used so
that they disappear when they are not needed, e.g. a DECL_LOCK(name) macro
to declare the lock,
and a LOCK_ARG(name) macro to pass it if it's needed, or to pass zero
otherwise.

5) A way to write to a memory location with release semantics, e.g. at the
end of critical section entered with compare-and-swap.  (My impression is
that on X86 this is just an assignment, but it requires some magic to tell
the compiler not to move other operations past it.  An empty volatile asm
seems to do the trick with gcc, but may be overkill.  On Itanium this is a
st.rel instruction.  On many other architectures it might require an
explicit memory barrier, or an atomic update of a local.)

6) Everything needs to be in the system reserved part of the C namespace,
since it should be usable from C, but also from standard C++ headers.

If there's some consensus that this would be a step in the right direction,
I'm willing to generate such a header file for the platforms I have easy
access to.  But we would need to get at least some agreement that this also
makes sense for C++ .  (I can also put in fetch and add explicitly, if that
would help convince people.)

Hans

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]