2006/5/22, Francis C. [email protected]:
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 not
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).
No, it will change with regard to timing but not with regard to
behavior (semantics).
The nightmare scenario is this: the client calls to say that your
mission-critical application stops running occasionally. It will be fine for
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 agree that getting MT programs right is harder than single threaded
applications - but that’s not a reason to basically disallow MT if it
fits the business problem well.
I suppose your answer to all this is: just code more carefully, and only use
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.
No, my answer is that your rule prevents proper implementation of
business requirements. The point of the short example I presented was
that you have to make a sequence of operations mutually exclusive in
order to implemente the business requirement (have a thread safe cache
that is filled as values are requested…). You have to allow this in
order to implement correct thread safe programs. If you allow for
variable assignment only then it’s overly complex to implement the
semantics I demonstrated. (btw, assignment can be a complex
operation, too - just thing of C++ operator overloading)
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.
I’m not religious here I just state the fact that your rule cripples
MT implementations.
Kind regards
robert