How influences the synchronized keyword on parameters of a synchr metod?
Hi
Given a class A where there is some fields and some synchronized methods. These methods are then protected from simultanious execution because of the (in)direct lock on "this".
My question: Is a specific parameter of a synchronized method protected from access by external objects that have their own synchronized methods that uses this specific parameter?
Visualisation:
Class A {
public synchronized void someMethod(Date date) {
...
date.setTime(someLongValue);
}
}
Class B {
public synchronized void someOtherMethod(Date date) {
...
date.setTime(someOtherLongValue);
}
}
, so say for instance there is two threads and both uses the same Date object which they concurrently try to use when thread1 calls the method in the instantiated class A and thread2 calls the method in the instantiated class B.
So the question is as well: Do we need a synchronized block on the date-object that surrounds the date.setTime method to obtain what we want which is that only one of these two methods are run at a time?
[1120 byte] By [
3numa] at [2007-10-3 4:47:19]
The methods will synchronize on the object they are invoked against.
Date date = new Date();
A a = new A();
a.someMethod(date); // will synchro on a
This will not prevent multiple threads from manipulating the date object concurrently.
Syncing does not protect data. It only protects blocks of code. The way you protect data is by properly syncing every block of code that accesses that data.
jverda at 2007-7-14 22:51:45 >
Class A and B{public void someOtherMethod(Date date) {synchronized (date) {date.setTime(someOtherLongValue);}
> Class A and B{
> public void someOtherMethod(Date date) {
>
> synchronized (date) {
> date.setTime(someOtherLongValue);
> }
That by itself doesn't protect that Date object.
Another thread can still modify it while you're in the sync block, unless every access to that Date object is in a block that's synced on the Date object.
jverda at 2007-7-14 22:51:45 >
That's the idea.Every thread that wants access to the date object must lock it.
> That's the idea.
>
> Every thread that wants access to the date object
> must lock it.
Well, must lock on some shared lock object, but yeah, that's it.
It wasn't clear to me from your example that you were also indicating all other accesses must sync as well.
jverda at 2007-7-14 22:51:45 >
As a matter of fact in the mentioned code
class A
{
public synchronized void someMethod(Date date)
{
date.setTime(someLongValue);
}
}
Some method doesnt even need to be synchronized because of thread confinement. This is a stateless class.
> As a matter of fact in the mentioned code
>
> > class A
> {
>public synchronized void someMethod(Date date)
> {
> date.setTime(someLongValue);
>
>
>
> Some method doesnt even need to be synchronized
> because of thread confinement. This is a stateless
> class.
The fact that A and B are stateless is somewhat irrelevant. There is insufficient information in the example to determine whether or not the given Date object is thread confined.
The synchronization as given in the example is somewhat pointless, but presumably it was only being illustrative.
> As a matter of fact in the mentioned code
>
> > class A
> {
>public synchronized void someMethod(Date date)
> {
> date.setTime(someLongValue);
>
>
>
> Some method doesnt even need to be synchronized
> because of thread confinement. This is a stateless
> class.
Date is not stateless, and that's whats relevant here. At least, I assume that's what he was talking about when he posted it.
jverda at 2007-7-14 22:51:45 >
Thank you for all your answers!
They answered my questions well.
So basically a synchronized block should be around the date reference when ever date it is used.
Or one could make the reference to the date field volatile. So only when the date is to be used more than once in a block a synchronized block should be used as I see it.
In the later volatile case should all references to date be declared volatile then or only when the Date is created(the later right?) ?
3numa at 2007-7-14 22:51:45 >
