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 cach
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 synch
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
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 scalab
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 concur
, LLC
- 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
On 2003.02.13 14:42 Larry Sanderson wrote:
> ... ...
>
> 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?
Not personally. I think they are unlikely
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, is
... ...
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 acheive by being allowed this much leniency in their
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 = local
ginal 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 modifications
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)
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 (foo
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
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]
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 it,
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 l
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
work.
-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 cl
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)
{
Hi Scott,
This is copy on write.
It works best when modifications are infrequent
compared to access.
e.g. connecting to a jms topic (modification)
and broadcasting messages to the connections (iteration).
Dain's version would copy on every message, rather than
only when a client connects/disconne
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 clie
22 matches
Mail list logo