synchronize process wide ?

Discussion in 'Java' started by lyallex, Jun 6, 2004.

  1. lyallex

    lyallex Guest

    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
    lyallex, Jun 6, 2004
    #1
    1. Advertising

  2. 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)
    Lee Fesperman, Jun 7, 2004
    #2
    1. Advertising

  3. On Mon, 07 Jun 2004 05:45:18 GMT, Lee Fesperman
    <> 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
    Duncan Strang, Jun 7, 2004
    #3
  4. Duncan, Strang wrote:
    >
    > On Mon, 07 Jun 2004 05:45:18 GMT, Lee Fesperman
    > <> 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)
    Lee Fesperman, Jun 8, 2004
    #4
  5. lyallex

    lyallex Guest

    On Mon, 07 Jun 2004 23:14:03 GMT, Lee Fesperman
    <> wrote:

    >Duncan, Strang wrote:
    >>
    >> On Mon, 07 Jun 2004 05:45:18 GMT, Lee Fesperman
    >> <> 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
    lyallex, Jun 8, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Leroy Tanner

    How To Synchronize FPGAs

    Leroy Tanner, Sep 22, 2004, in forum: VHDL
    Replies:
    4
    Views:
    1,084
    Don Golding
    Sep 24, 2004
  2. Web Developer

    char 8bit wide or 7bit wide in c++?

    Web Developer, Jul 31, 2003, in forum: C++
    Replies:
    2
    Views:
    579
    John Harrison
    Jul 31, 2003
  3. Disc Magnet
    Replies:
    2
    Views:
    706
    Jukka K. Korpela
    May 15, 2010
  4. Disc Magnet
    Replies:
    2
    Views:
    785
    Neredbojias
    May 14, 2010
  5. Martin Rinehart

    80 columns wide? 132 columns wide?

    Martin Rinehart, Oct 31, 2008, in forum: Javascript
    Replies:
    16
    Views:
    176
    John W Kennedy
    Nov 13, 2008
Loading...

Share This Page