Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > synchronize process wide ?

Reply
Thread Tools

synchronize process wide ?

 
 
lyallex
Guest
Posts: n/a
 
      06-06-2004
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

 
Reply With Quote
 
 
 
 
Lee Fesperman
Guest
Posts: n/a
 
      06-07-2004
lyallex wrote:
>
> 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.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
 
Reply With Quote
 
 
 
 
Duncan Strang
Guest
Posts: n/a
 
      06-07-2004
On Mon, 07 Jun 2004 05:45:18 GMT, Lee Fesperman
<(E-Mail Removed)> wrote:

>> 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.


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
 
Reply With Quote
 
Lee Fesperman
Guest
Posts: n/a
 
      06-07-2004
Duncan, Strang wrote:
>
> On Mon, 07 Jun 2004 05:45:18 GMT, Lee Fesperman
> <(E-Mail Removed)> wrote:
>
> >> Hi
> >>
> >> Say I have the following (pointless) code
> >>
> >> ...
> >>
> >> 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.
> >>
> >> ...
> >>
> >>
> >> 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.

>
> 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.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
 
Reply With Quote
 
lyallex
Guest
Posts: n/a
 
      06-08-2004
On Mon, 07 Jun 2004 23:14:03 GMT, Lee Fesperman
<(E-Mail Removed)> wrote:

>Duncan, Strang wrote:
>>
>> On Mon, 07 Jun 2004 05:45:18 GMT, Lee Fesperman
>> <(E-Mail Removed)> wrote:
>>
>> >> Hi
>> >>
>> >> Say I have the following (pointless) code
>> >>
>> >> ...
>> >>
>> >> 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.
>> >>
>> >> ...
>> >>
>> >>
>> >> 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.

>>
>> 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".


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

>> 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.


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.

>
>> 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.


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
80 character wide <pre> block appears only 60 character wide onWindows Disc Magnet HTML 2 05-15-2010 06:53 AM
Re: DSLR lenses not good wide open at wide angle? Dauphin de Viennois Digital Photography 2 07-16-2008 12:29 PM
Wide Screen not wide enough? michelebargeman@yahoo.com DVD Video 31 04-27-2006 08:50 PM
Not many "wide-angle" compacts but, heck, many are wide-angle anyway! JeffOYB@hotmail.com Digital Photography 10 01-09-2006 08:30 AM
char 8bit wide or 7bit wide in c++? Web Developer C++ 2 07-31-2003 08:09 AM



Advertisments