quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lehuen <nicolas.leh...@gmail.com>
Subject Re: FileSession.py - improved? version
Date Mon, 11 Apr 2005 19:06:44 GMT
On Apr 11, 2005 6:35 PM, Jim Gallacher <jg.lists@sympatico.ca> wrote:
> Hi Nicolas,
> 
> Attached is a new version of FileSession.py that uses a different
> locking scheme. In a "well duh" kind of moment I thought why not just
> check if the session is locked before trying to lock the file? It seems
> to work so I've changed the default locking back on.

The reason why I haven't done this before is because lock reentrance
is not as simple as it seems. We need a rock solid solution here, a
proven solution, because threading bugs are such a mess to debug that
we can't afford to see one appear. So we'll have to check all corner
cases, such as :

1) What if two threads / two processes enter are initializing their
session "at the same time" ? What if there was a thread switch between
the moment the self._locked==1 test is done and the moment the lock is
performed ? In that case, the session would be locked twice, then
unlocked once, which could cause problems.

2) What if self.locked==1, so we skip locking, then immediatly there's
a thread switch and the lock is released in another thread ? In that
case, the session would not be locked at all, with possible problems
if a third thread tries to read while we're writing.

So the reentrancy check really needs to be atomically performed with
the lock, which is not something you can easily do if you don't have a
bit of hardware (or virtual machine) support, somewhere. And don't
even get me started with the problem of double-checked locking...

Fortunately, those two cases are made impossible by the fact that the
FileSession instances are not shared between threads. Each thread has
its own copy of the FileSession, the data being shared between threads
by loading and saving data to a file in a serial fashion. So the two
cases above won't happen, and we can safely utter this "well, duh",
now that we've carefully thought about it :) Consequently, I've
checked in your code.

> Tested with and without session locking and have not seen any problems
> so far:
> ab -n 500000 http://localhost/session_test.py
> 
> Regards,
> Jim
> 
> 
>

Mime
View raw message