From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-22T23:14:35+09:00
Subject: Re: sysread changes behavior in the presence of threads?

------=_Part_199741_544411.1148307272381
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

We're threadjacking, so I'll keep it short. The point of taking a very
restrictive view of synchronization is to prevent incorrect concurrency.
Your example depends on the implementation of aMap and of calculateValue no=
t
to do evil things. (One of the evil things they can do is simply to run for
several milliseconds, or make a blocking I/O call. This can give you a bad
case of mutex contention, which is exceptionally costly in many modern
implementations.) This means that the program may change behavior with
respect to concurrency across platforms, hardware, and also across time (as
the code inside those called functions changes). Ruby adds the further
dimension that the code you call under lock may have been metaprogrammed on
the fly.

The nightmare scenario is this: the client calls to say that your
mission-critical application stops running occasionally. It will be fine fo=
r
a month, and then it will stop twice in one week. You ask what did they do
differently, and the answer is always "nothing." You ask what your
programmers changed, and the answer is always "nothing." The problem is of
course completely non-reproducible. This is not a nice place to be, since
you can't just blame the client's environment.

I suppose your answer to all this is: just code more carefully, and only us=
e
well-debugged libraries. That of course is a partially-correct answer, but
achievable in practice only at some specific cost. My larger point is that
in the case of threads, this balance-point is often very hard to achieve at
reasonable cost.

I'll let you have the last word, both because we're offtopic, and because
threading is a religious issue to many people and so the question tends to
generate more heat than light :-). In my defense, I'll only say that my
dislike of threads is rooted in many years of experience, and not a mere
prejudice.

On 5/22/06, Robert Klemme <shortcutter@googlemail.com> wrote:
>
> 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, an=
d
> 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: NEVE=
R
> > 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
>
>

------=_Part_199741_544411.1148307272381--