Use of synchronized variables over synchronized methods?

[Pep]

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.

 

[Ingo R. Homann]

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

 

[Chris Uppal]

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

 

[Pep]

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:


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]

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.

 

[Thomas Hawtin]

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

 

[Pep]

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.