One needs to make use of CAS or LL/SC hardware instructions. These can be used
to implement lock-free synchronization.
Nuno Lucas <[EMAIL PROTECTED]> wrote:
On 5/31/07, Eduardo Morras wrote:
> At 23:25 30/05/2007, you wrote:
> >Setting and reading individual bytes (u8 in sqlite-speak) are not
> >threadsafe either. Only reading/setting entire entire words
> >are threadsafe on most architectures.
>
> Using a uint32 for store the flags is threadsafe. There are less than 32
> true/false values and read/set is simple. I see no difference doing
>
> if (uint8==0){ // read/test bit
> uint8=1; // set bit
> whatever more
> }
Not atomic, so not thread-safe.
You have a race condition waiting to happen.
> and
>
> if (uint32&&MASK){ // read/test bit
> uint32&&=MASK; // set bit
> whatever
> }
Also not atomic, so not thread-safe.
> in speed, and a compiler should not make worse code on last one. So say
>
> >> Also, my take on bitfields is that they are not thread/multi processor
> >> friendly (there is no
> >> atomic "set bit"), and also compilers typically don't optimize well with
> >> that (so before
> >> applying this patch, I would test on other platforms than gcc linux x86).
>
> is not true.
It's true not all CPUs have an atomic "set bit" operation.
Regards,
~Nuno Lucas
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
