MyObject myObject = concurrenthashmap.get(key)
this does a sync lock that is also used when later on doing this:
concurrenthashmap.put(key,myObject);
So if you just look at those 2 statements then myObject can never be
Not fully initialized when another thread does the first statement
Because else a concurrent hashmap is just bogus...
So because of the 2 syncs (the get is also a sync that is not the case in the double check locking problem that is described everywhere)
i think this case must go ok. and the other sync just assures that a markup is loaded twice.
The problem if we let it just be (that we also could do) is that in developer we also have 2 monitoring instances monitoring the same markup
But because of the syn the get does use i think this is not the typical double check locking case..
johan
On 1/14/06, Jonathan Locke <
[EMAIL PROTECTED]> wrote:
uh, sorry... i wasn't reading closely enough. i don't think it's wise
to do this even if you (think) you can get away with it. if you want to
be synchronized, be synchronized. don't try to avoid it or you're
likely to get burned. but even if you don't get burned, everyone is
going to wonder about it.
Jonathan Locke wrote:
>
> the reason for this has to do with the semantics of synchronized on
> muli-processor systems. until you actually enter the synchronized
> block order of operations on memory is not guaranteed because of
> processor cache (in)coherency.
>
> Jonathan Locke wrote:
>>
>> i'm not 100% sure that it's a problem in this case, but generally
>> speaking, double checked locking does not work in java because of the
>> underlying memory model.
>>
>> Igor Vaynberg wrote:
>>> i think the concurrenthashmap guards against multiple threads
>>> writing into it, using it as a whiteboard. but in our case i think
>>> you still have to do the doublecheck, otherwise how do you guarantee
>>> that the createObject() is only called once?
>>>
>>> myObject = createMyObject();
>>> concurrenthashmap.put(key,myObject);
>>>
>>> this is safe to do w/out any sync blocks if you dont mind
>>> createMyObject() being possibly called twice or more times.
>>>
>>> -Igor
>>>
>>> On 1/14/06, *Johan Compagner* <[EMAIL PROTECTED]
>>> <mailto:[EMAIL PROTECTED] >> wrote:
>>>
>>>
>>>
>>> MyObject myObject = concurrenthashmap.get(key)
>>> if(myObject == null)
>>> {
>>> synchronize(concurrenthashmap)
>>> {
>>> myObject = concurrenthashmap.get(key);
>>> if(myObject == null)
>>> {
>>> myObject = createMyObject();
>>> concurrenthashmap.put(key,myObject);
>>> }
>>> }
>>> }
>>> return myObject;
>>>
>>>
>>> If the concurrenthashmap was a just variable that you want to test
>>> or set like this?:
>>>
>>>
>>> MyObject myObject = myInstance;
>>> if(myObject == null)
>>> {
>>> synchronize(concurrenthashmap)
>>> {
>>> myObject = concurrenthashmap.get(key);
>>> if(myObject == null)
>>> {
>>> myObject = createMyObject();
>>> myInstance = myObject;
>>> }
>>> }
>>> }
>>> return myObject;
>>>
>>>
>>> then we would have the double check problem because the assignment
>>> of myInstance = myObject can be rearranged by the compiler
>>> so another thread would already read the reference but to an
>>> invalid not constructed/fully written object.
>>>
>>> But in our case we use a concurrenthashmap which if the key is not
>>> found does a sync internally and that sync is also used
>>> in the put again.
>>> So the question is if i understand synchronization at that level
>>> completely right that this piece of code:
>>>
>>> myObject = createMyObject();
>>> concurrenthashmap.put(key,myObject);
>>>
>>> should result in a fully constructed object in the
>>> concurrenthashmap because inside he put there is a sync yes?
>>>
>>> I am a bit confused because of this:
>>>
>>> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
>>>
>>> <http://www.cs.umd.edu/%7Epugh/java/memoryModel/DoubleCheckedLocking.html>
>>>
>>> and then the part of "A fix that doesn't work" The big difference
>>> is ofcourse that we DO have a sync block on the null check
>>> in MyObject myObject = concurrenthashmap.get (key);
>>>
>>> This is all because i want to change MarkupCache.getMarkup()
>>> because i notice when i start hitting wicket in the repeater
>>> examples with 10 users at the same time almost all the time used
>>> is going into that method
>>> Because we are synching constantly on the markup cache and if the
>>> load is a bit high there is a large time spend because of that.
>>> And this is a pitty because after the initial webapplicaiton load
>>> and first pages hit. there doesn't have to be a sync what so ever
>>> because all the markup is already loaded!
>>> And this can be done by using a concurrenthashmap there but we do
>>> need to sync if there isn't a markup yet so that we don't load it
>>> twice
>>>
>>> If i change the code i get 10% more speed when doing the same test.
>>>
>>> johan
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
>> log files
>> for problems? Stop! Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> _______________________________________________
>> Wicket-develop mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Wicket-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
