You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2013/04/20 17:57:00 UTC
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
Re: Removing synchronization on metadata?
Posted by Adam Estrada <es...@gmail.com>.
Awesome! Thanks Martin
On Sat, Apr 20, 2013 at 12:30 PM, Martin Desruisseaux <
martin.desruisseaux@geomatys.fr> wrote:
> Hello Adam and Chris
>
> Thanks, I'm committing the removal. I will report the SVN reversion number
> on SIS-85 in case we would want to revert.
>
> Martin
>
>
> Le 20/04/13 18:09, Adam Estrada a écrit :
>
> Hi Martin,
>>
>> I can't think of a use case where a user would want to actually modify
>> metadata mid process. Let's remove it. If someone else objects to this let
>> it be known!
>>
>> Adam
>>
>
>
Re: Removing synchronization on metadata?
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Adam and Chris
Thanks, I'm committing the removal. I will report the SVN reversion
number on SIS-85 in case we would want to revert.
Martin
Le 20/04/13 18:09, Adam Estrada a écrit :
> Hi Martin,
>
> I can't think of a use case where a user would want to actually modify
> metadata mid process. Let's remove it. If someone else objects to this let
> it be known!
>
> Adam
Re: Removing synchronization on metadata?
Posted by Adam Estrada <es...@gmail.com>.
Hi Martin,
I can't think of a use case where a user would want to actually modify
metadata mid process. Let's remove it. If someone else objects to this let
it be known!
Adam
On Sat, Apr 20, 2013 at 11:57 AM, Martin Desruisseaux <
martin.desruisseaux@geomatys.fr> wrote:
> 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
>
>
Re: Removing synchronization on metadata?
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
+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: chris.a.mattmann@nasa.gov
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 <ma...@geomatys.fr>
Organization: Geomatys
Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
Date: Saturday, April 20, 2013 8:57 AM
To: Apache SIS <de...@sis.apache.org>
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
>