[concurrency-interest] synchronize design

Peter Veentjer alarmnummer at gmail.com
Thu Feb 8 05:02:53 EST 2007


Hi Rajesh

You are creating a lot of objects, but modern virtual machines have a
very good performance (a lot of recycling). So unless you have very
high performance requirements, I don't think it is an issue. You could
create a benchmark and check if the performance is acceptable.

And it is true that you need locking (the workqueue does it for you).
But locking is not as expensive as it was once. The locks that cause
problems are locks that are kept for a long time (you get lock
contention). And in both cases (with a read/writelock and with an
executor) you could get lock contention (especially with futures). But
if you don't have to do a lot of stuff in that strucure, and you don't
need to access slow io devices, I don't think it would be a problem
(although I don't know enough of your requirements).

The technique I describe, is also explained in "Java Concurrency in
Practice" and I have used it in a few projects, and it works like a
dream. Concurrency control related complexity is reduced quite a lot
(unlike with rwlocks) and performance has always been good enough.

On 2/8/07, Rajesh Balamohan <rbalamohan at sonoasystems.com> wrote:
>
>  Peter - It was a different perspective on approaching synch issues.
>
>  I was just wondering about the performance in this case. If we follow this
> approach compared to ReadWriteLocks, won't we be creating lots of objects
> and queueing and dequeiing (which internally might be using locks?).
>
>  Wont it add it more cost to do the synch operation?
>
>  ~Rajesh.B
>
>
>  Peter Veentjer wrote:
>  Another solution would be the following:
>
> Create an Executor with a single thread and let this thread
> communicate with the structure (if the structure is accessed by a
> single thread, you don't need concurrency control in the structure
> itself).
>
> If a client want to read something, it creates a runnable, places it
> on the executor and by using a Future the thread can wait for
> completion and the result. The same goes for the writes.
>
> And to give writes a higher priority than the reads, you could use a
> BlockingQueue as workQueue that is able to deal with priorities. Items
> with a higher priority fall through faster than items with a lower
> priortity (give the writes a higher priority than the reads).
>
> I guess there are lots of other solutions, but I don't have enough
> information to give a good answer.
>
>
>
>
>
> On 2/7/07, Rajesh Balamohan <rbalamohan at sonoasystems.com> wrote:
>
>
>  Can you try checking ReadWrite Locks in JDK 1.5 for this?.. Aquire the
> write lock only when you want to change it.
>
> ~Rajesh.B
>
> sidali ikhlef wrote:
>
>
>  Hi,
>
> I have multiple threads accessing a shared class called Resources, witch is
> composed of many other objects such as Current Activity, current environment
> ..... I want to synchronize the access to this resource but not using simple
> mechanisms like synchronize or synchronize(this). Any help or referencing
> will be appreciated.
>
> Precision: writing to the resource must have higher priority than reading
> and the chronology is very important to keep data coherent.
>
> Regards.
>
> _________________________________________________________________
> MSN Messenger: appels gratuits de PC à PC !
> http://www.msn.fr/newhotmail/Default.asp?Ath=f
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
>  _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>



More information about the Concurrency-interest mailing list