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 <[EMAIL PROTECTED]> 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 >
