You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter <ji...@zeus.net.au> on 2013/06/11 14:23:11 UTC
Immutable Entry
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?
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.
Re: Immutable Entry
Posted by Peter <ji...@zeus.net.au>.
To answer your earlier question, yes there were a lot of issues in the existing codebase, more so in the qa suite.
The biggest obstacle to overcome with an incremental upgrade approach will be finding stable points and determining what to leave out.
An initial step release might be to leave out new org.apache.river infrastructure, it's difficult to tell at this stage how stable a release with only some of the concurrency fixes might be, given that it stil hasn't quite stabilised yet, however we are very close, having fixed a swathe of issues.
On another topic, the last commited changes appears related to the arm test failures, there's a loop with a wait call that releases synchronization, the method used to terminate the loop was changed from using synchronization to using a volatile field, this may allow the loop to break out earlier. I'm not sure whether it's just changed timing or is directly influencing it.
Please have a look and see what you think:
http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src/com/sun/jini/outrigger/OperationJournal.java?view=log
Regards,
Peter.
----- Original message -----
>
> See comments below...
>
> Greg.
>
> On Tue, 2013-06-11 at 15:32, Peter wrote:
> > 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.
> >
>
> We can't control what the client does.
>
> > 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.
> >
> Although important, it's not urgent. So don't beat yourself to death
> over it. I'm focussed on the container for now. Also how to
> incorporate all the trunk changes in an orderly fashion.
>
> > 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 <tr...@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.
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Immutable Entry
Posted by Greg Trasuk <tr...@stratuscom.com>.
See comments below...
Greg.
On Tue, 2013-06-11 at 15:32, Peter wrote:
> 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.
>
We can't control what the client does.
> 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.
>
Although important, it's not urgent. So don't beat yourself to death
over it. I'm focussed on the container for now. Also how to
incorporate all the trunk changes in an orderly fashion.
> 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 <tr...@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.
> > > > >
> > > >
> > >
> >
>
Re: Immutable Entry
Posted by Peter <ji...@zeus.net.au>.
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 <tr...@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.
> > > > >
> > > >
> > >
> >
>
Re: Immutable Entry
Posted by Peter <ji...@zeus.net.au>.
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 <tr...@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.
> > > >
> > >
> >
>
Re: Immutable Entry
Posted by Gregg Wonderly <gr...@wonderly.org>.
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 <tr...@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.
>>>
>>
>
Re: Immutable Entry
Posted by Greg Trasuk <tr...@stratuscom.com>.
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.
> >
>
Re: Immutable Entry
Posted by Peter <ji...@zeus.net.au>.
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.
>
Re: Immutable Entry
Posted by Peter <ji...@zeus.net.au>.
Although a user dev could use final fields in their own Entry implementations and perhaps should even be encouraged to do so, an immutable Entry could be simply reconstructed with the modified state before being submitted back into a space.
What appears to be one object has many copies across distributed nodes, one more local copy won't hurt.
I'm thinking about a best practices web page for user devs.
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.
>
Re: Immutable Entry
Posted by Greg Trasuk <tr...@stratuscom.com>.
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.