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 12:45:32 GMT
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.



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

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