river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Immutable Entry
Date Tue, 11 Jun 2013 14:28:55 GMT
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
View raw message