Synchronizing the access to SCADefinitions

[Ramkumar R <ra...@gmail.com>]

Hi All, I am new to Tuscany Community, being interested in contributing and
trying to catch up. Right now am going through the code to get a feel of it
and the threading issue (as mentioned in
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29138.html) seems
to be something simple that I can fix to try a hand with Tuscany.



Looking at the current implementation SCADefinitionsImpl.java uses java
ArrayList to store the list of policy sets, intents, binding types etc.
Possible solutions to this issue woule be to



a) synchronize the methods that does the operations like clear/addAll OR

b) replace the existing ArrayList with Vectors OR

c) replace the existing ArrayList with CopyOnWriteArrayList (new with
Java1.5)



Option (a) seems to be a bad idea for me as it would lock the entire method,
instead i would go for option (b) OR (c).



Going for option (b), using Vectors OR Collections.synchronizedList
synchronizes your list object. However, the iterators implemented in the
java.util Collections classes are fail-fast, which means that if one thread
changes a collection while another thread is traversing it through an
Iterator, the next Iterator.hasNext() or Iterator.next() call will throw
ConcurrentModificationException. If we have to prevent
ConcurrentModificationException, we must lock the entire List while you are
iterating by wrapping it with a synchronized block, which inturn is costly.



Option (c) seems to be a good solution to the above problem, the
CopyOnWriteArrayList class from util.concurrent (which will also appear in
the java.util.concurrent package in JDK 1.5) is a thread-safe implementation
of ArrayList that offers far better concurrency. Multiple reads can almost
always execute concurrently, simultaneous reads and writes can usually
execute concurrently, and multiple simultaneous writes can often execute
concurrently. Also CopyOnWriteArrayList contains a mutable reference to an
immutable array, so as long as that reference is held fixed, you get all the
thread-safety benefits of immutability without the need for locking.



I have opened a JIRA (Tuscany-2170) to fix this issue. Please suggest me if
this one is the right approach.
-- 
Thanks & Regards,
Ramkumar Ramalingam

Re: Synchronizing the access to SCADefinitions

[Greg Dritschler <gr...@gmail.com>]

Oops, meant to say "...than contributions adding definitions."

On Fri, Apr 4, 2008 at 4:00 PM, Greg Dritschler <gr...@gmail.com>
wrote:

> Ramkumar,
>
> Sorry for the delay in responding.  I think you are probably right that
> CopyOnWriteArrayList is the way to go.  Presumably there will be far more
> contributions traversing the definitions (looking for policy sets etc) than
> contributions adding to the contributions.  So trading off a high penalty on
> write for no penalty on traversal sounds like a good idea.  The write
> penalty could be mitigated by batching updates; i.e. instead of adding new
> intents, policy sets, etc. to the lists one-by-one, collect them and make
> one update to each list.
>
> Greg Dritschler
>
>
> On Wed, Apr 2, 2008 at 5:56 AM, Ramkumar R <ra...@gmail.com> wrote:
>
> > Hi All, I am new to Tuscany Community, being interested in contributing
> > and
> > trying to catch up. Right now am going through the code to get a feel of
> > it
> > and the threading issue (as mentioned in
> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29138.html)
> > seems
> > to be something simple that I can fix to try a hand with Tuscany.
> >
> >
> >
> > Looking at the current implementation SCADefinitionsImpl.java uses java
> > ArrayList to store the list of policy sets, intents, binding types etc.
> > Possible solutions to this issue woule be to
> >
> >
> >
> > a) synchronize the methods that does the operations like clear/addAll OR
> >
> > b) replace the existing ArrayList with Vectors OR
> >
> > c) replace the existing ArrayList with CopyOnWriteArrayList (new with
> > Java1.5)
> >
> >
> >
> > Option (a) seems to be a bad idea for me as it would lock the entire
> > method,
> > instead i would go for option (b) OR (c).
> >
> >
> >
> > Going for option (b), using Vectors OR Collections.synchronizedList
> > synchronizes your list object. However, the iterators implemented in the
> > java.util Collections classes are fail-fast, which means that if one
> > thread
> > changes a collection while another thread is traversing it through an
> > Iterator, the next Iterator.hasNext() or Iterator.next() call will throw
> > ConcurrentModificationException. If we have to prevent
> > ConcurrentModificationException, we must lock the entire List while you
> > are
> > iterating by wrapping it with a synchronized block, which inturn is
> > costly.
> >
> >
> >
> > Option (c) seems to be a good solution to the above problem, the
> > CopyOnWriteArrayList class from util.concurrent (which will also appear
> > in
> > the java.util.concurrent package in JDK 1.5) is a thread-safe
> > implementation
> > of ArrayList that offers far better concurrency. Multiple reads can
> > almost
> > always execute concurrently, simultaneous reads and writes can usually
> > execute concurrently, and multiple simultaneous writes can often execute
> > concurrently. Also CopyOnWriteArrayList contains a mutable reference to
> > an
> > immutable array, so as long as that reference is held fixed, you get all
> > the
> > thread-safety benefits of immutability without the need for locking.
> >
> >
> >
> > I have opened a JIRA (Tuscany-2170) to fix this issue. Please suggest me
> > if
> > this one is the right approach.
> > --
> > Thanks & Regards,
> > Ramkumar Ramalingam
> >
>
>

Re: Synchronizing the access to SCADefinitions

[Greg Dritschler <gr...@gmail.com>]

Ramkumar,

Sorry for the delay in responding.  I think you are probably right that
CopyOnWriteArrayList is the way to go.  Presumably there will be far more
contributions traversing the definitions (looking for policy sets etc) than
contributions adding to the contributions.  So trading off a high penalty on
write for no penalty on traversal sounds like a good idea.  The write
penalty could be mitigated by batching updates; i.e. instead of adding new
intents, policy sets, etc. to the lists one-by-one, collect them and make
one update to each list.

Greg Dritschler

On Wed, Apr 2, 2008 at 5:56 AM, Ramkumar R <ra...@gmail.com> wrote:

> Hi All, I am new to Tuscany Community, being interested in contributing
> and
> trying to catch up. Right now am going through the code to get a feel of
> it
> and the threading issue (as mentioned in
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29138.html)
> seems
> to be something simple that I can fix to try a hand with Tuscany.
>
>
>
> Looking at the current implementation SCADefinitionsImpl.java uses java
> ArrayList to store the list of policy sets, intents, binding types etc.
> Possible solutions to this issue woule be to
>
>
>
> a) synchronize the methods that does the operations like clear/addAll OR
>
> b) replace the existing ArrayList with Vectors OR
>
> c) replace the existing ArrayList with CopyOnWriteArrayList (new with
> Java1.5)
>
>
>
> Option (a) seems to be a bad idea for me as it would lock the entire
> method,
> instead i would go for option (b) OR (c).
>
>
>
> Going for option (b), using Vectors OR Collections.synchronizedList
> synchronizes your list object. However, the iterators implemented in the
> java.util Collections classes are fail-fast, which means that if one
> thread
> changes a collection while another thread is traversing it through an
> Iterator, the next Iterator.hasNext() or Iterator.next() call will throw
> ConcurrentModificationException. If we have to prevent
> ConcurrentModificationException, we must lock the entire List while you
> are
> iterating by wrapping it with a synchronized block, which inturn is
> costly.
>
>
>
> Option (c) seems to be a good solution to the above problem, the
> CopyOnWriteArrayList class from util.concurrent (which will also appear in
> the java.util.concurrent package in JDK 1.5) is a thread-safe
> implementation
> of ArrayList that offers far better concurrency. Multiple reads can almost
> always execute concurrently, simultaneous reads and writes can usually
> execute concurrently, and multiple simultaneous writes can often execute
> concurrently. Also CopyOnWriteArrayList contains a mutable reference to an
> immutable array, so as long as that reference is held fixed, you get all
> the
> thread-safety benefits of immutability without the need for locking.
>
>
>
> I have opened a JIRA (Tuscany-2170) to fix this issue. Please suggest me
> if
> this one is the right approach.
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>