Firstly thanks for a fascinating mailing list,
Secondly,
As someone involved in implementing Thread.join etc I would
chip in that although implementation issues are obviously
secondary to the utility, naturalness and ease of use from the end users
point
of view - from the bottom up (i.e. from an implementation point of view)
ease of implementation, natural fit to the underlying model and ease of
implementation (and this
often translates to efficiency) are also very useful and in our imperfect
world
often lead to more consistent and trouble free implementations by different
vendors.
In the C and POSIX/win32 world that most JVM are implemented in
one picks up the common update semantics that volatile is required to get
the compiler to always flow updates to the memory rather than caching in
a register and mutex passing (including the mutexs that are used to
implement condition/event wait/notify protection) is the lowest common
denominator for guaranteeing update visibility across threads in
the various consistency models.
Join is frequently implemented via a pthread_cond_wait or equivalent
so it is natural that the mutex passed with the condition notify should
cause memory update visibility - if implemented in a 'natural' manner.
I realise his is just the 'model' I have in my head and that I may actually
be in a minority to think along these lines?
Thirdly, and the real reason for putting pen to paper,
I was fascinated to read of the work involving 'virtual coarsening' by
James Corbett and others
(http://www2.ics.hawaii.edu/~corbett/tr/ics-tr-97-10.ps.Z)
and wondered if anyone has done any work that makes an analogy between the
compaction of invisible events into the next local visible event for
inclusion
in the overall trace (thus compacting the state space of the model) and the
compaction of cache updates that usually result in (but do not necessarily
immediately require) memory
synchronisation? Could this produce a dynamic element to the (costly)
synchronization
behavior that would not be visible to the Java level user but which might
compose
multiple synchronizations in the underlying layer?
Has there been other work on dynamically altering the amount of underlying
synchronization while maintaining a consistent semantics in the layer
above?
Gordon Hutchison
AIX JVM development
IBM Java Technology Centre,
IBM Hursley, UK.
Notes: Gordon Hutchison/UK/IBM
Internet: gordon_hutchison@uk.ibm.com
Phone: (+44)/(0) 1962 815646 (Internal IBMUK-245646)
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:30 EDT