I had this type of discussion when I first joined these lists,
it was regarding the use of the volatile keyword with Ole. I
hope this summary helps to shed some light on the problem.
The double checking issue has two problems, the one relevant
to this discussion is the behaviour of processor
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);
This seems backwards to me. I usually do something like this:
class X
{
HashMap clients = new HashMap();
public void someMethod()
{
synchronized(clients)
{
m.put(dc, cq);
}
...
}
public void someOtherMethod()
{
HashMap
iterator.remove()
Regards,
Adrian
From: Scott M Stark [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Why are we using this bogus construct
Date: Thu, 13 Feb 2003 09:20:53 -0800
I have seen this usage construct in a few places in the code and it makes
Assuming that iteration in someOtherMethod does not
change the map, ie, that the only updates are in
someMethod then it seems thread safe to me.
When someMethod is called it any ongoing iterations
will still be safe because the iterator is refering
to the old map that was copied, the insert is
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)
{
.
-Original Message-
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 13, 2003 12:36 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Why are we using this bogus construct
This seems backwards to me. I usually do something like this:
class X
{
HashMap clients
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
This one looks to me as if it is not subject to double-checked locking type
problems. I think it is fine, since the copy is made in a synchronized
block and accessed in the same thread.
david jencks
On 2003.02.13 12:35 Dain Sundstrom wrote:
This seems backwards to me. I usually do something
Looks like you might be digging through some mq code
:)
I don't think that construct is too bogus... It
provides a copy write hashmap. Once the hashmap has
been updated, the rest of the read methods can treat
the hashmap as an imutable. No one will update that
hashmap ever again. To update
Yep.. your way is valid too but you take a
synchronization hit on every read. The otherway, the
performace hit is on the write. As I said previously,
if you read the map ALLOT more than you write to it,
then it makes sense to do it backwards.
Regards,
Hiram
--- Dain Sundstrom [EMAIL PROTECTED]
Hiram,
This type of construct creates some trick code. You iterate over the
keys, and I assume somewhere in the code you do clients.get(key). Well
there is no guarantee the the key is associated. I bet there are a ton
of other issues as your iterator in the read phase drifts from reality
of
Isn't double checked locking something like this:
private HashMap cache = new HashMap();
public MyObject get(String cacheLookup) {
MyObject foo = (MyObject)cache.get(cacheLooku);
if (foo == null) {
synchronized (cache) {
foo = cache.get(cacheLooku);
if
On 2003.02.13 13:40 Larry Sanderson wrote:
Isn't double checked locking something like this:
private HashMap cache = new HashMap();
public MyObject get(String cacheLookup) {
MyObject foo = (MyObject)cache.get(cacheLooku);
if (foo == null) {
synchronized (cache) {
Group, LLC
- Original Message -
From: Adrian Brock [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, February 13, 2003 9:54 AM
Subject: Re: [JBoss-dev] Why are we using this bogus construct
Hi Scott,
This is copy on write.
It works best when
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 =
... do a bunch of reading on double checked locking ...
OK - I think I see where you are coming from now. Wow - I have to agree
with Joshua Bloch: wildly counterintuitive. Have you ever experienced
these things failing in the way you describe? How much performance gain
do VM's really
I'd just like to say that I believe David is exactly right here. I've
been following (or rather trying and failing most of the time) the
javaMemoryModel (http://www.cs.umd.edu/~pugh/java/memoryModel/) mailing
list, and this kind of issue is very difficult to analyse correctly.
My advice, FWIW,
On 2003.02.13 14:42 Larry Sanderson wrote:
... do a bunch of reading on double checked locking ...
OK - I think I see where you are coming from now. Wow - I have to agree
with Joshua Bloch: wildly counterintuitive. Have you ever experienced
these things failing in the way you describe?
- Original Message -
From: Toby Allsopp [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, February 13, 2003 11:46 AM
Subject: Re: [JBoss-dev] Why are we using this bogus construct
I'd just like to say that I believe David is exactly right here. I've
been following
On Thursday, February 13, 2003, at 01:46 PM, Toby Allsopp wrote:
My advice, FWIW, is to stop messing around and just use util.concurrent
by Doug Lea
(http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/
intro.html).
There aren't many people who can prove that their tricky
Just as a reminder: the uncontended case for a synchronized statement
is VERY fast: about 13 PowerPC instructions. I would argue safety
first, use Java synchronization where possible, or advanced data
structures from the concurrent package if not. If a piece of code turns
out to be a
good point. I'll have to review the code in more
detail.
--- Dain Sundstrom [EMAIL PROTECTED] wrote:
Hiram,
This type of construct creates some trick code. You
iterate over the
keys, and I assume somewhere in the code you do
clients.get(key). Well
there is no guarantee the the key is
Do I get to update the CachedConnectionManager with the code from jb4
first? :-))
david
On 2003.02.13 15:40 Stefan Reich wrote:
Just as a reminder: the uncontended case for a synchronized statement
is VERY fast: about 13 PowerPC instructions. I would argue safety
first, use Java
24 matches
Mail list logo
