Use of synchronized variables over synchronized methods?

Discussion in 'Java' started by Pep, Aug 15, 2005.

  1. Pep

    Pep Guest

    I need to let a number of threaded objects change the state of a singular
    object by use of setter methods.

    What would be the better approach to synchronise based on a couple of
    boolean variables. Should I use a couple of synchronised method members or
    make the boolean variables synchronised?

    class x
    // using synchronised methods
    {
    boolean A = false;
    boolean B = false;

    public synchronized void setA()
    {
    a = true;
    }

    public synchronized void unsetA()
    {
    a = false;
    }

    private synchronized void basedOnAandB()
    {
    if ((a) && (!b))
    {
    // do something
    }
    }
    }

    class x
    // using synchronised variables
    {
    SynchronizedBoolean A = new SynchronizedBoolean(false);
    SynchronizedBoolean B = new SynchronizedBoolean(false);

    public void setA()
    {
    A.set(true);
    }

    public void unsetA()
    {
    A.set(false);
    }

    private void basedOnAandB()
    {
    if (A.equals(B.equals(false)))
    {
    // do something
    }
    }
    }

    Note, I am assuming that because the B.equals method is called from the
    parameter list of the A.equals method that this is as close as I can get to
    a logical "and" operation that has the B variable locked for the duration
    of the "A" method call.

    TIA,
    Pep.
     
    Pep, Aug 15, 2005
    #1
    1. Advertising

  2. Hi Pep,

    If your class is really that simple, the first version might be OK
    (depending onb its usage).

    Note however, we had a thread about synchronization the last days, and
    that in most cases, synchronizing methods is not sufficient (see my
    List-example)!

    Note also, that the following will not mean the same:

    > if ((a) && (!b))
    > if (A.equals(B.equals(false)))


    Ciao,
    Ingo
     
    Ingo R. Homann, Aug 15, 2005
    #2
    1. Advertising

  3. Pep

    Chris Uppal Guest

    Pep wrote:

    > private synchronized void basedOnAandB()
    > {
    > if ((a) && (!b))
    > {
    > // do something
    > }
    > }


    This is the /only/ safe way of combining the two values, therefore you /must/
    use a synchronised method, as above, or synchronised blocks.

    -- chris
     
    Chris Uppal, Aug 15, 2005
    #3
  4. Pep

    Pep Guest

    Ingo R. Homann wrote:

    > Hi Pep,
    >
    > If your class is really that simple, the first version might be OK
    > (depending onb its usage).
    >
    > Note however, we had a thread about synchronization the last days, and
    > that in most cases, synchronizing methods is not sufficient (see my
    > List-example)!
    >
    > Note also, that the following will not mean the same:
    >
    >> if ((a) && (!b))
    >> if (A.equals(B.equals(false)))

    >
    > Ciao,
    > Ingo


    Thanks for the response.

    The simplified class in my example was purely for example. The actual class
    will be a listening socket class used in a 3 tier client/server environment
    so I take it by your response that synchronized variables are the way to go
    then.

    Thanks for the pointer about the different meaning of the boolean
    conditional example I showed, I did not take too much time over it as it
    was for the example but it is definitely something i was looking towards so
    I will spend more time making sure it does what I want it to do :)

    Cheers,
    Pep.
     
    Pep, Aug 15, 2005
    #4
  5. Pep

    Pep Guest

    Chris Uppal wrote:

    > Pep wrote:
    >
    >> private synchronized void basedOnAandB()
    >> {
    >> if ((a) && (!b))
    >> {
    >> // do something
    >> }
    >> }

    >
    > This is the /only/ safe way of combining the two values, therefore you
    > /must/ use a synchronised method, as above, or synchronised blocks.
    >
    > -- chris


    Yes thanks, I came to that conclusion but required another person to tell me
    this which you and Ingo now have.

    As I said to Ingo, this simple example is actually to try a technique that i
    will employ in a client/server environment so it's best to be safe :)

    In essence once I have gained the value of B it is not really a problem if
    another method changes it while I am checking A and doing something based
    on the result and will only really mean that another client will be
    serviced before the listener shuts down but the way I am with things I
    would just like to keep everything synchronised as closely as I possibly
    can.

    Cheers,
    Pep.
     
    Pep, Aug 15, 2005
    #5
  6. Pep wrote:
    > Chris Uppal wrote:
    >
    >>Pep wrote:
    >>
    >>> private synchronized void basedOnAandB()
    >>> {
    >>> if ((a) && (!b))
    >>> {
    >>> // do something
    >>> }
    >>> }


    > In essence once I have gained the value of B it is not really a problem if
    > another method changes it while I am checking A and doing something based
    > on the result and will only really mean that another client will be
    > serviced before the listener shuts down but the way I am with things I
    > would just like to keep everything synchronised as closely as I possibly
    > can.


    That's a long sentence. :) e careful not to synchronise over too much.
    You // do something could easily do something to deadlock. You might
    want a small synchronised (this) block to do the minimum that needs to
    be done, and then call the rest outside.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Aug 15, 2005
    #6
  7. Pep

    Pep Guest

    Thomas Hawtin wrote:

    > Pep wrote:
    >> Chris Uppal wrote:
    >>
    >>>Pep wrote:
    >>>
    >>>> private synchronized void basedOnAandB()
    >>>> {
    >>>> if ((a) && (!b))
    >>>> {
    >>>> // do something
    >>>> }
    >>>> }

    >
    >> In essence once I have gained the value of B it is not really a problem
    >> if another method changes it while I am checking A and doing something
    >> based on the result and will only really mean that another client will be
    >> serviced before the listener shuts down but the way I am with things I
    >> would just like to keep everything synchronised as closely as I possibly
    >> can.

    >
    > That's a long sentence. :) e careful not to synchronise over too much.
    > You // do something could easily do something to deadlock. You might
    > want a small synchronised (this) block to do the minimum that needs to
    > be done, and then call the rest outside.
    >
    > Tom Hawtin


    Yep I fell foul of that before.

    There are a number of synchronized methods to be used on the main class but
    they will only ever be called from 2 places, the main class and the
    controlling class.

    Note the use of the fullstop there :)

    The controlling class will only ever call one when the operator (human)
    wants to control the daemon and the main class uses one to reference the
    controlling variables to know if it should stop processing.

    Cheers,
    Pep.
     
    Pep, Aug 15, 2005
    #7
    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. Jerry
    Replies:
    4
    Views:
    131,848
    tonni
    Aug 11, 2010
  2. Ian Pilcher
    Replies:
    17
    Views:
    752
    Thomas G. Marshall
    Nov 15, 2005
  3. dmcreyno
    Replies:
    9
    Views:
    9,568
    Mark Space
    Jun 27, 2006
  4. ankur
    Replies:
    4
    Views:
    1,446
    Eric Sosman
    Nov 28, 2008
  5. Kenneth McDonald
    Replies:
    5
    Views:
    325
    Kenneth McDonald
    Sep 26, 2008
Loading...

Share This Page