Critical sections and mutexes

[brueckd at tbye.com]

On 24 Oct 2001, David Bolen wrote:

> > I was merely responding to somebody's not-entirely-true assertion that
> > "_every_ access to that [shared] resource _must_ be enclosed in locks".
>
> But that statement is more true than not (as other respondents have
> shown, even a simple assignment may be an issue)

Maybe, maybe not. Like I said before, it depends entirely on your
application, and is not a hard and fast rule by any means. A ton of the
locking work I have to do in other languages revolves around preventing
the type of corruption that leads to crashes, and this is what the
interpreter gives me for free.

> There are some cases (e.g., when performing read-only access to a
> value where it isn't critical if the value changes and you just get
> one of the two potential values, such as when watching a sentinel that
> you'll just pick up on the next loop), but you really do need to
> consider all possible users of every shared resource.

That's true either way. With a very few multithreaded Python apps under
your belt it gets so that it doesn't take too many brain cycles to
recognize the GIL-does-this-for-free scenarios. Yes, you can always
overengineer a solution if you want, but that's not very Pythonic.

Think of it this way: the way the GIL works can impose a slight
performance hit on your program (a cost). With that cost is an associated
benefit. You can choose whether or not to enjoy that benefit, but you've
already paid the cost so you might as well.

 -Dave