http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50065

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org
         Resolution|                            |INVALID

--- Comment #2 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-08-13 
10:10:47 UTC ---
> instruction 2C, clrb [%g1] corresponds to inline function 'spinlock_unlock'
>     *(volatile unsigned char*)lock = 0;
> 
> This happens before the lock protected content 'remap_barrier++', i.e.
> 
>   30:   c6 00 a0 00     ld  [ %g2 ], %g3
>   34:   86 00 e0 01     inc  %g3
>   38:   81 c3 e0 08     retl 
>   3c:   c6 20 a0 00     st  %g3, [ %g2 ]     ---> use the branch delay slot
> 
> This is wrong and will cause serious lock issues under a multithreading
> environment.

On what grounds is this wrong exactly?  The end of the code is equivalent to:

volatile unsigned char lock;
int remap_barrier;

remap_barrier++;
lock = 0;

It is perfectly valid for an optimizing C compiler to swap the two lines.

You want something like:

static inline void spin_unlock(char *lock)
{
    __asm__ __volatile__("stb %%g0, [%0]" : : "r" (lock) : "memory");
}

Reply via email to