List:Falcon Storage Engine« Previous MessageNext Message »
From:Vladislav Vaintroub Date:March 23 2009 2:04am
Subject:RE: Deadlock detector accesses deleted Transaction?
View as plain text  
So , the bug was a race condition leading to livelock
http://bugs.mysql.com/bug.php?id=37251 

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
> instead
> > 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
> else
> thought it would be a good idea, so the problem was fixed with the
> mentioned
> 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
> full
> 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


Thread
Deadlock detector accesses deleted Transaction?Olav Sandstaa22 Mar
  • Re: Deadlock detector accesses deleted Transaction?Kevin Lewis23 Mar
    • Re: Deadlock detector accesses deleted Transaction?Olav Sandstaa23 Mar
      • Re: Deadlock detector accesses deleted Transaction?Kevin Lewis24 Mar
        • Re: Deadlock detector accesses deleted Transaction?Olav Sandstaa24 Mar
  • RE: Deadlock detector accesses deleted Transaction?Vladislav Vaintroub23 Mar
    • RE: Deadlock detector accesses deleted Transaction?Vladislav Vaintroub23 Mar