> Isn't the second example "more gentle" by acquiring a less intrusive
> lock?
>
> I suppose that performance-wise I won't see much differences, but
> /technically/, is there a difference (synchronization-wise)?
Your SynchedBoolean example has one technical advantage over the other
one: since it uses a separate lock object, it doesn't need to contend
with other synchronized methods in the main class. However since
you've kept requestStop() in the main class synchronized even when
using SynchedBoolean, the advantage is lost.
You could achieve a similar effect without the extra class by
declaring a special lock object in the main class, and explicitly
synchronizing on that in methods for setting and getting the value of
the stopRequested boolean. However the extra class encapsulates this
nicely and could also be used elswhere.
I notice that you use synchronized(this) explicitly in the
SynchedBoolean class, but when the entire method body is within the
synchronized block that's equivalent to simply specifying the methods
synchronized.
/gordon

Signature
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e
Remon van Vliet - 04 May 2006 10:03 GMT
>> Isn't the second example "more gentle" by acquiring a less intrusive
>> lock?
[quoted text clipped - 20 lines]
>
> /gordon
And to comment on your SynchedBoolean class, have a look at this
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/atomic/AtomicBoolea
n.html
Also, java.util.concurrent provides very elegant locking/concurrency
mechanisms that eliminate most needs for synchronized methods or blocks.
- Remon
Ingo R. Homann - 04 May 2006 12:33 GMT
Hi Remon,
> Also, java.util.concurrent provides very elegant locking/concurrency
> mechanisms that eliminate most needs for synchronized methods or blocks.
What do you mean with this? In my opinion, it is much easier to use
synchronized methods or blocks than to do the locking manually.
(I am aware that synchronized blocks are sometimes not flexible enogh,
so that is necessary to do locking manually, but that is a different
topic, and especially is no contradiction to what I just said...)
Ciao,
Ingo
shypen42@yahoo.fr - 04 May 2006 15:06 GMT
...
> And to comment on your SynchedBoolean class, have a look at this
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/atomic/AtomicBoolea
n.html
Excellent... I wasn't aware of this. And that class maily does the
trick by encapsulating a boolean flag declared as... volatile!
(which I said I didn't want to use, but it was just to try to
understand a little bit better how synchronization works,
now I'll probably just use AtomicBoolean if/when I need such
a feature)
:)
thanks,
shypen42@yahoo.fr - 04 May 2006 14:53 GMT
...
> Your SynchedBoolean example has one technical advantage over the other
> one: since it uses a separate lock object, it doesn't need to contend
> with other synchronized methods in the main class.
Ah excellent! This is exactly what I was thinking :)
> However since
> you've kept requestStop() in the main class synchronized even when
> using SynchedBoolean, the advantage is lost.
Damn, my mistake and good catch... I made the error here
in my post, but not in my programs.
The whole point was of course to remove the "synchronized"
on that method in the main class.
> You could achieve a similar effect without the extra class by
> declaring a special lock object in the main class, and explicitly
> synchronizing on that in methods for setting and getting the value of
> the stopRequested boolean. However the extra class encapsulates this
> nicely and could also be used elswhere.
Yup... I actually wrote that extra class after finding
myself repeating such code a few times.
:)
> I notice that you use synchronized(this) explicitly in the
> SynchedBoolean class, but when the entire method body is within the
> synchronized block that's equivalent to simply specifying the methods
> synchronized.
Correct! Code fixed asap ;)
Thanks a lot for your thoughtful reply,