So , the bug was a race condition leading to livelock
As I cannot find original patch with SyncObject attached to the bug, I tend
to think it was a discussion during the Friday call about it and fancy
interlocked won by points. I cannot believe I would introduce lock-free by
myself, I'm too pessimistic about optimistic locking;)
> -----Original Message-----
> From: Vladislav.Vaintroub@stripped [mailto:Vladislav.Vaintroub@stripped]
> On Behalf Of Vladislav Vaintroub
> Sent: Monday, March 23, 2009 2:48 AM
> To: Olav.Sandstaa@stripped; 'FalconDev'
> Subject: RE: Deadlock detector accesses deleted Transaction?
> > -----Original Message-----
> > From: Olav.Sandstaa@stripped [mailto:Olav.Sandstaa@stripped]
> > Sent: Sunday, March 22, 2009 11:59 PM
> > To: FalconDev
> > Subject: Deadlock detector accesses deleted Transaction?
> > Note also the following comment in the header of the
> > Transaction::waitForTransaction():
> > // Note:
> > // Deadlock check could use locking, because there are potentially
> > concurrent
> > // threads checking and modifying the waitFor list.
> > // Instead, it implements a fancy lock-free algorithm that works
> > reliably only
> > // with full memory barriers. Thus "volatile"-specifier and
> > COMPARE_EXCHANGE
> > // are used when traversing and modifying waitFor list. Maybe it is
> > better to
> > // use inline assembly or intrinsics to generate memory barrier
> > of
> > // volatile.
> > I do not quite understand the purpose of the following use of
> > "volatile" in the above code:
> > volatile Transaction *trans;
> > Hopefully after a some hours of sleep I might have a good idea for
> > what happens and how to fix this.
> As I recall it, this was me fixing some bug (I'll lookup bzr history
> tomorrow for exact bugnr and problem). If memory serves me right, I
> originally wanted to introduce a SyncObject on waitingFor list. Nobody
> thought it would be a good idea, so the problem was fixed with the
> fancy interlocked stuff after review.
> If you remove volatile from the declaration above, compilation will
> fail on
> Visual Studio compiler with
> Transaction.cpp(997) : error C2440: '=' : cannot convert from 'volatile
> Transaction *' to 'Transaction *'
> Conversion loses qualifiers
> Transaction::waitingFor is volatile , therefore this line
> for (trans = transaction->waitingFor; trans; trans = trans->waitingFor)
> would fail because of conversion(s) that loses qualifier.
> Why volatile at all? Some compilers, notably Visual Studio, generate a
> memory barrier on volatile. However C/C++ standard declares "volatile"
> behavior implementation dependent, and I would not count on this
> property in
> all cases.
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe: http://lists.mysql.com/falcon?unsub=1