Solving the problem of mutual recursion

[Peter Brooks]

On May 27, 12:16 am, Chris Angelico <ros... at gmail.com> wrote:
> On Mon, May 27, 2013 at 5:35 AM, Ian Kelly <ian.g.ke... at gmail.com> wrote:
> > I'm pretty sure that CPython uses the GIL regardless of platform.  And
> > yes you can have multiple OS-level threads, but because of the GIL
> > only one will actually be running at a time.  Other possibilities
> > include:
>
> 6) It's spinning in a function that has released the GIL. Python
> threads can certainly execute concurrently; they just can't be
> manipulating Python objects. Most of the I/O functions will release
> the GIL before doing a potentially-blocking operation, and some
> CPU-heavy functions can do the same (I'm given to understand that
> numpy does this) - just depends on having a long job that involves no
> refcounted objects.
>
This makes complete sense - any atomic action should be atomic, so two
threads can't be doing it at the same time. They can be doing anything
else though.

If two threads create a new object at the same time, for example,
there's potentially the problem that they'll get the same space, so
the object will be owned by both. To prevent this, the new object call
should be run in only one thread.

If you have two objects running their methods on their own local
variables, then there's no potential for conflict, so there's no need
for them to be blocked.

This is an interesting subject.. There's nothing wrong with the tool
I'm using to report threads - 'Activity Monitor' is the standard
process monitor. It counts cores as 'CPUs', which seems perfectly
reasonable to me. As I said, other Unixes, such as HP-UX, do the same
thing.

I'm not quite sure of the best way to examine the exact behaviour.
Since the blocking works at the level of atomic operations, it's
difficult to detect - a call to an atomic operation may block all
other threads, but any snapshot of the number of active threads won't
be running at this time, so will only report when there are multiple
threads active.