From: Robert Klemme <shortcutter@...>
Date: 2006-05-22T22:42:05+09:00
Subject: Re: sysread changes behavior in the presence of threads?

2006/5/22, Francis Cianfrocca <garbagecat10@gmail.com>:
> With teams I manage, when it's necessary to
> use threads, I impose strict rules on when and how to apply mutexes, and how
> to design synchronization sets. As long as my rules are followed, you
> generally won't see a deadlock, and you will rarely see severe mutex
> contention. But most programmers hate following them. (Among them: NEVER
> call a function under lock, not even one you wrote, not even an inline or a
> macro. Only variable reads and writes are allowed.)

I can see why they hate sticking to that rule.  Basically you disallow
decent synchronization of functional parts of the application. The
consequence of this is that you either do not have concurrent programs
that are correct or you force people to implement their own mutex on
top of your rule.  To give an example what I mean, your rule prohibits
this typical cache idiom:

// pseudo code
synchronized ( lock ) {
   if ( ! aMap.contains( myKey ) ) {
      // cache miss
      aMap.put( myKey, calculateValue( key ) );
   }
}

IMHO your ruly makes multi threaded applications pretty much pointless.

Kind regards

robert