No, I don't think you can remove the synchronisation

Assume

Thread     Statement
T1         localMap[T1] = new HashMap(clients);
T1         doSomething(localMap[T1]); // Add some stuff
T2         localMap[T2] = new HashMap(clients)
T2         doSomething(localMap[T2]);
T2         clients = localMap[T2];
T1         clients = localMap[T1]; // Oops, lose adds from T2

Regards
/Mikael


>In fact, you can 
>remove the synchronized block below and everything is still perfectly 
>thread safe. The whole point is that the member variable "clients" is 
>*NEVER* modified - only assigned to.  In fact, it would drive the 
point 
>home even more if you did this:
>
>private Map clients = Collections.EMPTY_MAP;
>
>public void someMethod()
>{
>     HashMap localMap = null;
>     localMap = new HashMap(clients);
>     // ... read/write work on local map ...
>     clients = Collections.unmodifiableMap(localMap);
>}
>
>public void someOtherMethod()
>{
>     HashMap localMap = clients;
>     // ... read-only work on local map ...
>}
>
>Here, clients is always immutable, even though someMethod is able to 
>update it with a new value.  No synchronization, yet perfectly thread 
>safe (although very expensive to modify).
>
>-Larry
>
>David Jencks wrote:
>> I think you are wrong, although I have trouble understanding all 
the issues
>> with this.  I think this is a "double checked locking" idiom and 
I think it
>> is just as broken.
>> 
>> The guy who calls someOtherMethod will definitely see the correct 
hashmap,
>> but there is no guarantee that its state will match any particular 
state in
>> which it was put unless access to it is also synchronized.
>> 
>> Double checked locking is broken.
>> 
>> See Effective Java pp 193 ff and the various Double Checked Locking 
is
>> Broken websites.
>> 
>> As I understand it, problems with this construct are unlikely 
to appear
>> unless you are using something like a multiprocessor alpha box.
>> 
>> I think we should prove in some way that this construct is safe 
or remove
>> it.
>> 
>> david jencks
>> 
>> On 2003.02.13 13:00 Larry Sanderson wrote:
>> 
>>>If the map is seldom modified, then you can get around synchronization 

>>>with techniques like this.  It is taking advantage of the fact that 
>>>assignement is an atomic operation.  If the methods are like this:
>>>
>>>public void someMethod()
>>>{
>>>    HashMap localMap = null;
>>>    synchronized (clients)
>>>    {
>>>       localMap = new HashMap(clients);
>>>    }
>>>    // ... read/write work on local map ...
>>>    clients = localMap;
>>>}
>>>
>>>public void someOtherMethod()
>>>{
>>>    HashMap localMap = clients;
>>>    // ... read-only work on local map ...
>>>}
>>>
>>>Now everyone can call someOtherMethod() without invoking the cost of 
>>>synchronization, and once they obtain localMap it is guaranteed 
not to 
>>>be modified.  But someMethod() exists for those rare times when 
the map 
>>>does need to be modified.
>>>
>>>I don't think this is as useful as it once was - synchronization 
is much 
>>>faster than it used to be.
>>>
>>>-Larry
>>>
>>>Scott M Stark wrote:
>>>
>>>>I have seen this usage construct in a few places in the code and it
>>>
>>>makes
>>>
>>>>no sense to me:
>>>>
>>>>class X
>>>>{
>>>>    HashMap clients = new HashMap();
>>>>
>>>>    public void someMethod()
>>>>    {
>>>>       synchronized(clients)
>>>>        {
>>>>            HashMap m = new HashMap(clients);
>>>>            m.put(dc, cq);
>>>>            clients=m;
>>>>       }
>>>>        ...
>>>>    }
>>>>    public void someOtherMethod()
>>>>    {
>>>>        Iterator i = clients.keySet().iterator();
>>>>        while( i.hasNext() )
>>>>        {
>>>>            ...
>>>>        }
>>>>    }
>>>>}
>>>>
>>>>The unsynchronized clients HashMap is synchronized and copied when
>>>>modified and accessed without synchronization in other contexts.
This
>>>
>>>is
>>>
>>>>not thread safe for the accesses and makes for very expensive 
updates.
>>>>Why isn't the HashMap simply synchronized and used without copying?
>>>>
>>>>xxxxxxxxxxxxxxxxxxxxxxxx
>>>>Scott Stark
>>>>Chief Technology Officer
>>>>JBoss Group, LLC
>>>>xxxxxxxxxxxxxxxxxxxxxxxx
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
>>>>are you planning your Web Server Security? Click here to get a FREE
>>>>Thawte SSL guide and find the answers to all your  SSL security 
issues.
>>>>http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>>>>_______________________________________________
>>>>Jboss-development mailing list
>>>>[EMAIL PROTECTED]
>>>>https://lists.sourceforge.net/lists/listinfo/jboss-development
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
>>>are you planning your Web Server Security? Click here to get a FREE
>>>Thawte SSL guide and find the answers to all your  SSL security 
issues.
>>>http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>>>_______________________________________________
>>>Jboss-development mailing list
>>>[EMAIL PROTECTED]
>>>https://lists.sourceforge.net/lists/listinfo/jboss-development
>>>
>>>
>> 
>> 
>> 
>> -------------------------------------------------------
>> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
>> are you planning your Web Server Security? Click here to get a FREE
>> Thawte SSL guide and find the answers to all your  SSL security 
issues.
>> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>> _______________________________________________
>> Jboss-development mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>-------------------------------------------------------
>This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
>are you planning your Web Server Security? Click here to get a FREE
>Thawte SSL guide and find the answers to all your  SSL security issues.
>http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>_______________________________________________
>Jboss-development mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/jboss-development
>




===================================================================
Skickat genom Swedish Connection WebMail
===================================================================




-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to