quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gallacher <jg.li...@sympatico.ca>
Subject Re: FileSession.py - improved? version
Date Mon, 11 Apr 2005 22:57:19 GMT
Nicolas Lehuen wrote:
> 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.

I've reviewed your comments and walked through the code again just to 
make sure. Looks OK, since as you point out each thread gets it's own 
copy of FileSession.

There will still be a race condition when session locking is off, but at 
least the integrity of the session files is preserved. This race 
condition should be noted in the forthcoming documentation though. As 
someone commented earlier, if the user turns session locking off, they 
better know what they are doing.

One thorny issue I've chosen to ignore so far is the lack of file 
locking in the do_cleanup method. Lots of interesting suprises hiding 
there, I'm sure.


View raw message