river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Immutable Entry
Date Tue, 11 Jun 2013 19:50:12 GMT
JEP 169: Value Objects, the project lead is John Rose.

----- Original message -----
> Currenty Entry objects are packaged in a MarshalledWrapper by Outrigger's and
> Reggie's proxy code.  By making fields in MarshalledWrapper final, we can
> achieve safe publication in River.  This doesn't help Entry's shared among
> threads in client code performing calculations and storing results in an Entry
> prior to being submitted back to a Javaspace.
>
> Because Entry fields are public, we can't do much to ensure client code is
> sharing them safely.
>
> I'm more concerned client code will perform unsafe mutations that are outside
> our control.  In that case a Javaspace proxy might not see the last write to an
> Entry field.
>
> Perhaps all we can do is create a web page with best practices?
>
> I could really use a hand getting this set up, I'm bogged down at present and
> don't feel like I'm making much progress.  The positive discussion about these
> issues is heartening.
>
> I did see an Oracle blog post that proposed immutable arrays as a feature in a
> future Java version.
>
> Thanks,
>
> Peter.
>
> ----- Original message -----
> > It is very important for us to get this "publish" stuff nailed down so that
> > there are no problems that keep resurfacing because of this important part of
> > the JMM.
> >
> > We might need to look at the Unsafe class for help with "fences" that could
> > help us "commit" changes to memory in a way that eliminates locks, and keeps
> > developers from littering their code with things which while "necessary", are
> > subject to misuse, abuse and lack thereof, in such a way as to create these
> > mysterious behaviors which are almost always epic to discover the root cause.
> >
> > For example, using fences on java spaces "writes" as well as "reads" could be
> > an important "boundary" to establish between threads.  Inbound "notifications"
> > don't need fences except when they explicitly cross thread boundaries.  Using
> > "synchronized" on methods which change ownership between threads, has always
> > been the "correct" way to manage APIs which included threading.  But, volatile
> > since JDK1.5, has provided a non-blocking "correct" behavior for
> > non-array-content values.  If we don't want to use synchronized, then Unsafe
> > fences may be the only way to make things work for arrays as well.
> >
> > Gregg Wonderly
> >
> > On Jun 11, 2013, at 8:01 AM, Greg Trasuk <trasukg@stratuscom.com> wrote:
> >
> > >
> > > So if I understand correctly, we need to make sure that any parameters
> > > that are passed through the boundary of River code (e.g. anything that
> > > implements JavaSpace05) need to be marked volatile (can you do that on
> > > parameters) or stored to a volatile variable.  Or there needs to be a
> > > synchronized block that reads the queues.  That sounds moderately
> > > doable.  Is the volatility transitive?  i.e. If I make sure that an
> > > Entry is part of a "happens-before" event, are the fields on the objects
> > > referenced by that entry also published?
> > >
> > > Personally, synchronized is the only thing I've ever trusted.  When I
> > > see things like shared, non-synchronized variables, I think "There be
> > > dragons here".  Is there a lot of that in the codebase?
> > >
> > > Cheers,
> > >
> > > Greg.
> > >
> > >
> > > On Tue, 2013-06-11 at 08:45, Peter wrote:
> > > > Ok, so we need to make sure we safely publish an Entry to a volatile field
> > > > after modifications or make an Entry's fields volatile.
> > > >
> > > > Did you know that JERI uses a multiplexing thread pool core?
> > > >
> > > > Even when our code appears to be single threaded, once it's exported,
it
> > > > becomes visible to many threads.
> > > >
> > > > To avoid potential deadlock from dependant tasks executing out of order
> > > > JERI always creates a new thread if no free threads are available in its
> > > > internal thread pool.
> > > >
> > > > Regards,
> > > >
> > > > Peter.
> > > >
> > > > ----- Original message -----
> > > > >
> > > > > On Tue, 2013-06-11 at 08:23, Peter wrote:
> > > > > > I've been thinking about how Entry objects are immutable in
serialized
> > > > > > form and of course how they are not in unserialized form.
> > > > > >
> > > > > > Should Entry fields be final by default?
> > > > > >
> > > > >
> > > > > No.  Javaspaces usage is frequently to take an entry, modify it
and then
> > > > > put it back into the space.
> > > > >
> > > > > Greg.
> > > > >
> > > > > > The JMM makes an exception for Serialization, allowing final
fields to
> > > > > > be frozen after construction during deserialization, provided
it occurs
> > > > > > before sharing with other threads. It would allow Entry's to
be shared
> > > > > > safely among threads, as long as their public fields aren't
mutable,
> > > > > > eg: an array.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Peter.
> > > > >
> > > >
> > >
> >
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message