Are threads bad? - was: Future of Pypy?

[Marko Rauhamaa]

Paul Rubin <no.email at nospam.invalid>:

> Marko Rauhamaa <marko at pacujo.net> writes:
>> So why lock categorically like that? Java has a handy "synchronized"
>> keyword that wraps the whole method in "with self.lock". ...
>> Unfortunately, that deep locking analysis *is* required at every turn,
>> and mistakes *are* bound to happen.
>
> I wonder if synchronized was a mistake in Java. It confused me a lot
> when I tried to use it, but I never had to mess with it that much. I
> can't quite tell what your code is doing (why is it attempting a
> socket read with a lock held) and I'd be interested to see what an STM
> version would look like.

Synchronized methods are actually quite a powerful idea, but a bit
underappreciated by many Java developers.

The main point of my example is this:

 * Effective thread-safe programming would require some guidelines, a
   routine, a methodology so the code would be free of locking anomalies
   as a matter of course.

 * The industry hasn't formed such guidelines that are generally
   followed. That makes it difficult to glue together systems from
   components that come from different sources.

 * Even the best of guidelines have significant, surprising corner cases
   that require special treatment and are easy to get wrong.

 * As a corollary, you cannot implement thread-safety locally in a
   class. Instead, your locking decisions must be made application-wide.
   That violates encapsulation, which is a cornerstone of
   object-oriented programming (and large-system manageability).


Marko