Re: [Boost-users] Thread cancellation

From: Paul (elegant_dice_at_[hidden])
Date: 2005-02-10 21:04:44

> Paul,
> 
> When the flag has changed the memory semantics of your system maybe
> such that your cpu doesn't see the change for quite a while without
> memory barriers.
> 
> If it changes, say flip flops between true and false (not relevant to
> your case above), then you could end up with different values
> everywhere at once which may be inconvenient to your programs
> correctness.
> 

good lord, assembler?  doesn't the 'volatile' keyword fix the problem 
you describe?

if the flag is going to be flipping back and forth, then sure, even with 
memory barriers you will have threads which think the value is 
different... eg, you have 2 long-running threads that check the value 
and do some calculation that take 5 seconds or so.  lets assume they 
dont sync when reading the flag, so then thread A could check the flag 
and read false, while thread B checked the flag 4 seconds ago and 
currently thinks its true.  so you have inconsistencies there anyway, right?

otherwise, the flag is set and its only a matter of time before the CPU 
sees the correct value ('die' in the previous email's case) and dies. 
if the flag is for protecting resources, then of course you need 
volatile/guards/etc, otherwise it can be just a 'lazy cancel', when the 
thread finally reads the right value, it quits.  how many cycles-lag 
would that be anyway?  is this only a problem on exotic platforms?

is this cpu-cache problem actually a problem in this 'kill-flag' case, 
do you really think you need memory barriers on a flag like this?

thanks!
Paul