synchronize process wide ?

[lyallex]

Hi

Hi

Say I have the following (pointless) code

package head;

public class BrainBender{

private SomeClass sc = new SomeClass()

public void a(){
synchronized(Integer.class){
sc.doSomething() // might take a while
}
}

public void b(){
synchronized(Integer.class){
sc.doSomethingElse() //might take a long time
}
}
}

According to my understanding this would have the effect of
synchronizing on the unique Class object for Integer.

This means that regardless of where I used
synchronized(Integer.class) within the same process space it would
have the effect of providing mutual exclusion accross all such
synchronized blocks.

e.g

package garden; //nothing to do with head

public class Compost{

private Worm worm = new Worm();

public void blah(){
synchronized(Integer.class){
// ... access the Worm
}
}

//whatever
}

So if some Thread was currently executing b() in an instance of
BrainBender and this was taking a while, any thread that wanted to
access the Worm would have to wait for the lock on Integer.class

Is this correct ?

many thanks
Lyall

 

[Lee Fesperman]

Hi

Hi

Say I have the following (pointless) code

package head;

public class BrainBender{

private SomeClass sc = new SomeClass()

public void a(){
synchronized(Integer.class){
sc.doSomething() // might take a while
}
}

public void b(){
synchronized(Integer.class){
sc.doSomethingElse() //might take a long time
}
}
}

According to my understanding this would have the effect of
synchronizing on the unique Class object for Integer.

This means that regardless of where I used
synchronized(Integer.class) within the same process space it would
have the effect of providing mutual exclusion accross all such
synchronized blocks.

e.g

package garden; //nothing to do with head

public class Compost{

private Worm worm = new Worm();

public void blah(){
synchronized(Integer.class){
// ... access the Worm
}
}

//whatever
}

So if some Thread was currently executing b() in an instance of
BrainBender and this was taking a while, any thread that wanted to
access the Worm would have to wait for the lock on Integer.class

Is this correct ?

Yes it is (except with some classloader shenanigans).

It is also very bad coding ... really confusing and ostensibly useless.

 

[Duncan Strang]

Yes it is (except with some classloader shenanigans).

It is also very bad coding ... really confusing and ostensibly useless.

Er, OK. I'll bite

The question was not about the quality of the code was it, it was
about my understanding of the Class Object lock.

maybe this will make you feel better

private static SomeClass sc = new SomeClass()

If not perhaps you would care to explain what is so bad about the
code. I'm particularly interested on discovering how you would
synchronize access to an instance of a class for which you did not
have the source code.

Rgds
Lyall

 

[Lee Fesperman]

Er, OK. I'll bite

The question was not about the quality of the code was it, it was
about my understanding of the Class Object lock.

What's with the attitude? I answered your (?) question. You asked if your understanding
(as shown by your description above) was correct. My answer was "Yes it is".

BTW, are you the OP? You're posting using different From addresses. Are you Duncan or
Lyall? It would help me to know whether I'm talking to the OP or some troll.

maybe this will make you feel better

private static SomeClass sc = new SomeClass()

That doesn't really change things (see below).

If not perhaps you would care to explain what is so bad about the
code. ...

Several things:

java.lang.Integer is an immutable class. Since synchronization is about mutable fields,
synchronization has no meaning here (that I can think of). Using Integer implies that
your intention is to control access to Integer. However, nothing in your code shows this
to be the case.

Use of an external monitor is perfectly fine for controlling related accesses between
several classes. Besides indicating that your code was 'pointless', you also explicitly
stated there was no relation between the two synchronized blocks. In that case,
unrelated code shouldn't be using a common monitor. In addition, you are using a monitor
that is unrelated to either class. Jamming three unrelated classes together in an
implied relationship is very bad coding.

I'm particularly interested on discovering how you would
synchronize access to an instance of a class for which you did not
have the source code.

You didn't ask that question before. It's a hard question without further information.
Since you don't have the source code, synchronizing what's going on inside the class is
a complete shot in the dark. Even synchronizing on the instance or its class may
conflict with what the class code does. You could synchronize external access to the
instance, but I would suggest that you use an external monitor created explicitly for
that purpose.

 

[lyallex]

What's with the attitude? I answered your (?) question. You asked if your understanding
(as shown by your description above) was correct. My answer was "Yes it is".

Er, well I was a bit annoyed about the

"It is also very bad coding ... really confusing and ostensibly
useless"

I mean if you are going to make statements like that surely you should
back them up with reasons (which you have now done)

BTW, are you the OP? You're posting using different From addresses. Are you Duncan or
Lyall? It would help me to know whether I'm talking to the OP or some troll.

Yea, sorry about that. Too many things going on all at once
My given name is Duncan Strang, I usually post as lyallex because
Lyall is my middle name and one that is used at work to distinguish me
from other Duncans, stupid mistake I know, it won't happen again

That doesn't really change things (see below).


Several things:

java.lang.Integer is an immutable class. Since synchronization is about mutable fields,
synchronization has no meaning here (that I can think of). Using Integer implies that
your intention is to control access to Integer. However, nothing in your code shows this
to be the case.

Use of an external monitor is perfectly fine for controlling related accesses between
several classes. Besides indicating that your code was 'pointless', you also explicitly
stated there was no relation between the two synchronized blocks. In that case,
unrelated code shouldn't be using a common monitor. In addition, you are using a monitor
that is unrelated to either class. Jamming three unrelated classes together in an
implied relationship is very bad coding.

Yep, couldn't agree more and it's not something I was intending to do
'in production' It was just a way of trying to figure out just what
the implications were of doing this.

You didn't ask that question before. It's a hard question without further information.
Since you don't have the source code, synchronizing what's going on inside the class is
a complete shot in the dark. Even synchronizing on the instance or its class may
conflict with what the class code does. You could synchronize external access to the
instance, but I would suggest that you use an external monitor created explicitly for
that purpose.

Sure
I could do all sorts of things. I was just making sure I understood
this one little bit before moving on.

Anyway, thanks for taking the time to answer in the first place.
I'll try to construct my questions better in the future.

Rgds
Lyall


"Process- How will the work and the team be organized?
The team needs to fit the culture in which it will operate,
but you should write software well rather than preserve the
irrationality of an enclosing culture" - Kent Beck