Thread synchronization

Matthew Wesley mppw at carolina.rr.com
Wed Jan 3 12:01:02 PST 2007


On Thu, 30 Nov 2006 13:04:48 +0100
xs0 <xs0 at xs0.com> wrote:

> Sean Kelly wrote:
> > JohnC wrote:
> >> What's the recommended way to guard static variables?
> >>
> >> 1) synchronized by itself?
> >>
> >>   static Object getObj() {
> >>     synchronized {
> >>       return sharedVar;
> >>     }
> >>   }
> >>
> >> 2) synchronized on classinfo?
> >>
> >>   static Object getObj() {
> >>     synchronized (typeof(sharedVar).classinfo) {
> >>       return sharedVar;
> >>     }
> >>   }
> >>
> >> 3) synchronized on a static Object instance?
> >>
> >>   static this() {
> >>     syncLock = new Object;
> >>   }
> >>
> >>   static Object getObj() {
> >>     synchronized (syncLock) {
> >>       return sharedVar;
> >>     }
> >>   }
> >>
> >> I've seen all these patterns used. Are they all safe?
> > 
> > They're all safe.  Since #1 is in a static method, it will
> > synchronize on the ClassInfo object, just like you're doing
> > manually in #2.  And #3 just specifies a separate static object on
> > which to synchronize.  But since it's static, you'll get the same
> > effect.
> 
> I think the first one synchronizes only on the statement itself, so 
> while only one getObj can execute concurrently, it doesn't guard
> against a similar setObj()..
> 
> xs0

Perhaps I am misunderstanding the synchronized specification, as none
of these methods seem safe to me. When I read that "Synchronized allows
only one thread at a time to execute ScopeStatement" from
http://www.digitalmars.com/d/statement.html#SynchronizedStatement, that
seems to me that only the return statement is protected in any of these
cases, while any modification of the returned object is unsynchronized.

This seems to be what xs0 mentions above about #1, but how are #2 and
#3 any different?

On a related note,, the specification says that "where Expression
evaluates to an Object reference, allows only one thread at a time to
use that Object to execute the ScopeStatement." Doesn't this mean that
there is no way to synchronize separate critical sections? For example,
two or more critical sections that would block on the same mutex in a C
environment.


More information about the Digitalmars-d-learn mailing list