[ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope 2.X BIGSession problems - blocker - our site dies - need help of experienceZope developer, please)

[Chris McDonough]

On Wed, 2004-03-03 at 17:14, Tim Peters wrote:
> [Chris McDonough]
> > ...
> > The _data BTree is of course written to elsewhere in the code
> >
> (http://cvs.zope.org/*checkout*/Products/Transience/Transience.py?rev=1.32.1
> 2.2.2.2&content-type=text/plain)
> 
> That code is scary to me -- it talks about threads in the comments, but
> there's nary a mutex in sight.  If, for example, two threads happen to run
> _gc() simulateously, what's to stop one from deleting the same keys the
> other is crawling over?  Since it must be rare for two threads to get into
> _gc at the same time (but I don't see anything-- like a mutex --that
> guarantees to stop that), this theory may also fit the "rare and
> hard-to-reproduce failure" symptom.  It may in fact be safe against thread
> races, but if it is I don't see how.

I must misunderstand something.  Given that the code you're talking
about should raise a ReadConflictError in _gc (I am not using a ZODB
with MVCC) when two threads try to simultaneously access that data
structure where one attempts to obtain the results of "keys()" and the
other is attempting to delete a key, why would I need to protect that
access with a mutex?  There is no code in Zope AFAIK that employs a
mutex for simultaneous access to persistent data; if this is true, I
need to admit to not knowing the rules about knowing when a mutex is
required, and it will throw my world into a brief tailspin. ;-)

- C