Re: [pysqlite] Concurrency - first steps

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hugh Gibson wrote:
> It's not without issues, though. See for example
> http://blog.ianbicking.org/gil-of-doom.html 

I don't see what "issues" that highlights.  He reiterates that the GIL
affects a tiny corner case (all of those points).  Like him, I have yet
to hear of anyone who actually has a use case.

Unfortunately there are a lot of people who have a little knowledge
about threading and then run with it usually combining with some sort of
premature optimization.  A simple test is to ask about memory barriers.

> Our main application is a
> webserver with a thread farm for responding to HTTP requests. 

Do you have one thread per connection, or worker thread pool?

> I'm very interested in how it performs on MP machines with
> heavy loading.

That is exactly what you measure before the premature optimizations :-)

> Jython and IronPython avoid using the GIL and so may have significant
> performance advantages.

Actually they have immediate performance disadvantages.  All Python data
structures have to have mutexes so that two threads don't trash them.
Every single access has to acquire the mutex, do the access and then
release the mutex.  With the GIL the code just does the access.

A while back someone produced a Python 1.5 interpreter that was free
threaded.  In single threaded code it had around 50% performance of the
GIL based interpreter.  With multiple threads on a multiple processor
machine it barely managed to beat the GIL based interpreter and didn't
get much improvement with more than two processors because of lock
contention (Python uses mutable objects with everything shared).

In the big picture threading is a terrible way to get concurrency.  It
requires multiple processors to use the same memory.  That means
frequent cache clashing, synchronization, memory barriers etc.  Multiple
processes are far better since each processor can go full speed without
having to worry about the others.  Machines are also becoming more and
more NUMA - there is different amounts of RAM of different sizes and
speeds stuck around the place.  Some processors can access some of it
faster than others while others access other parts faster.  Once you
have multi-process concurrency working, it is trivial to make that also
work across machines providing the opportunity for even more concurrency.

There is even a Python 2.6/3 module to make it easy:
http://docs.python.org/whatsnew/2.6.html#pep-371-the-multiprocessing-package

> For portability I would like to keep open the
> possibility of moving to those platforms. Hence in all my coding I'm not
> assuming that the GIL exists.

I think you are confusing things.  The point of the GIL is to ensure
that Python data structures do not become corrupt.  For example there is
no operation you could do to a dict that will result in a crash.  The
other implementations have exactly the same property and behind the
scenes they use mutexes.

The example I gave in my previous email applies to all implementations.
 You can have race conditions.

> Threads are dangerous.

There are two types of dangerous.  One results in memory corruption and
crashes.  The other has unexpected results (race conditions) but at no
point are underlying Python data structures corrupted.

Python protects you from the first form in all implementations (CPython,
IronPython, Jython etc).  It doesn't protect you in the second form.
Java also made exactly the same decisions.  As an example that is why
all of its collection classes were synchronized.

> Why should Python insulate you from that danger at
> the expense of performance? I would like to be able to make that sort of
> decision myself.

Guido makes the decisions.  He is happy to get rid of the GIL if the
alternative doesn't have a significant performance impact on single
threaded code and actually shows benefits on multithreaded code.  Noone
has been able to show anything even close.

http://www.artima.com/weblogs/viewpost.jsp?thread=214235

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkj1tsACgkQmOOfHg372QRLTACfUIxCDw0XQNL4hjQHBoQmCGOi
Uu4AoIjdlD3DSzOfqtx+0g876WcOiBtl
=pmxl
-----END PGP SIGNATURE-----