Is it true that
1) the value of "clock" is set by the Garbage Collector,
2) so we can assume that this is a stop-the-world event, i.e. only the
GC runs, and no-one else.
3) If we then have several threads that concurrently call get() then
they should all be set to the same value ?
H
On Wed, 19 Jan 2005 16:40:47 -0500, Jeremy Manson <jmanson@cs.umd.edu> wrote:
> Hanson,
>
> If multiple threads write to the long this.timestamp concurrently,
> without using synchronization, then a thread that reads it could see any
> combination of the first 32 bits from any of those writes and the second
> 32 bits from any of those writes. This is true even if the reading
> thread is one of those that performed a write.
>
> So, yes, corruption is possible here.
>
> My recommendation would be to make the timestamp field volatile. There
> would be no corruption, and you would probably get a program that does
> what you want it to do (depending on what you want it to do).
>
> I'm less sure about what your second question is asking. From your
> example, it's unclear where the clock value is being set. So I can't
> tell you if every thread will have the same value for it. If it is a
> call to System.currentTimeMillis or System.nanoTime then that shouldn't
> be a problem.
>
> Soft/Weak references don't have any special memory semantics (other than
> those associated with GC).
>
> Jeremy
>
> Hanson Char wrote:
> > I refer to the latest jdk1.5. Just wonder what's this forum thought on the
> > SoftReferece.get() method:
> >
> > public T get() {
> > T o = super.get();
> > if (o != null) this.timestamp = clock;
> > return o;
> > }
> >
> > which updates the timestamp if necessary, but not being thread-safe in
> > that the timiestamp is of type long but there is no synchronization.
> >
> > So in theory if multiple threads get hold of the same SoftReference
> > and invoke the get method,
> >
> > 1) Can the timestamp result in a "corrupted" state ? Or,
> >
> > 2) Would all the thread then have the same clock value in their
> > working copies, and therefore will always update the timestamp with
> > that clock value ?
> >
> > What's the worst case scenario when this happened ? Should one bother
> > to synchronize on the SoftReference instance when this method is
> > invoked ?
> >
> > H
> > -------------------------------
> > JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
>
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:09 EDT