Hi Jim,

Until now, we suspected that the way global locks are handled could be
deadlock prone. You have just proved it.

I know that global locks are expensive on some systems, especially if
we want to use them in a multiprocess (forked) environment. That's why
we are forced to have such a small pool of global locks.

On the other hand, in a multithreaded environment, locks which are
valid for the whole process are not so expensive ; indeed, we can
create a whole bunch without bringing down the system (think about
Java where all object potentially have a monitor which is equivalent
to a lock).

I think this is a strong incentive to abandon the forked model and go
for the multi-threaded model (or the mono-threaded, asynchronous one).
For concurrency control, the forked model does not scale, apparently.

Regards,
Nicolas

2005/6/23, Jim Gallacher <[EMAIL PROTECTED]>:
> I think I just spotted a potential deadlock in psp.py.
> 
> def dbm_cache_store(srv, dbmfile, filename, mtime, val):
> 
>      dbm_type = dbm_cache_type(dbmfile)
>      _apache._global_lock(srv, "pspcache")
>      try:
>          dbm = dbm_type.open(dbmfile, 'c')
>          dbm[filename] = "%d %s" % (mtime, code2str(val))
>      finally:
>          try: dbm.close()
>          except: pass
>          _apache._global_unlock(srv, "pspcache")
> 
> "pspcache" will hash to one of 31 mutexes. Therefore there is a 1 in 31
> chance for a hash collision if a session is used in the same request,
> which would result in a deadlock.
> 
> I'm sure there are other possible deadlock scenarios where some
> combination of sessions and pspcache could end up trying to hold the
> same mutex.
> 
> Most obvious solution is to use the global lock 0, which will serialize
> all accesses to either pspcache.dbm (and the dbmsession dbm in the case
> where DbmSession is being used). This will result in an obvious
> performance hit when psp are used in conjunction with DbmSession, but
> that's better than a deadlock.
> 
> _apache._global_lock(srv, None, 0)
> 
> The alternative would be to reserve a mutex for pspcache.
> 
> If you agree that this is a possible deadlock let me know and I'll make
> the simple fix. We could also take another look at the bsddb transaction
> handling discussed last week in my Session benchmark post, and avoid
> using the mutex altogether.
> 
> Regards,
> Jim
>

Reply via email to