> -----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.
