+1 to remove it.

Thanks!

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: [email protected]
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++






-----Original Message-----
From: Martin Desruisseaux <[email protected]>
Organization: Geomatys
Reply-To: "[email protected]" <[email protected]>
Date: Saturday, April 20, 2013 8:57 AM
To: Apache SIS <[email protected]>
Subject: Removing synchronization on metadata?

>Hello all
>
>A while ago, we talked about metadata synchronization on this mailing
>list. If one take a look at any metadata class in
>"org.apache.sis.metadata.iso", we can see that all getter and setter
>methods are declared synchronized. In my understanding, it doesn't
>consume any space in the "*.class" files since the "synchronized"
>modifier only set a bit in the bytecodes (I verified that removing
>"synchronized" doesn't make any difference on the metadata *.class files).
>
>Nevertheless we mentioned the possibility to remove synchronization
>because it seems rarely needed in practice, since the most common
>pattern is to build a metadata in a single thread and keep it
>unmodifiable after construction. Furthermore, if someone really wants
>synchronization, he will probably needs something more elaborated (e.g.
>a lock on a whole metadata tree instead than on the instance of a
>particular property). On the other hand, removing synchronization reduce
>safety if a user read and write concurrently a metadata by accident.
>
>So I'm still not sure what is the best option. I'm heading toward
>removing synchronization, but if anyone think that we should keep them
>please let me know.
>
>     Martin
>

Reply via email to