Subj : Re: Memory visibility and the C compiler... ( a bit long )
To   : comp.programming.threads
From : SenderX
Date : Fri Jan 14 2005 11:38 am

> SenderX wrote:
> [...]
> > > Reordering across "critical instructions" (inline asm
> > > and/or external asm functions) is still possible (and is in fact
> > > desirable as long as it doesn't break anything).
> >
> > Are you talking about how the C compiler can reorder calls to external
> > assembled functions?
>
> Yes. For example, an external assembled function with the effect of
>
>   int f(...) {
>     return 42;
>   }
>
> can be reordered in all the ways you can imagine. Oder?

I see. I wonder how any pthread implementation gets around this fact? Most
pthread impls already use processor specific assembly to implement their
mutex api's. Could a compiler reorder variables around calls to a
lock-unlock function pair in a way that could mess things up?


> > I would greatly disapprove of a C compiler inspecting the instructions
of
> > my externally assembles routines!
>
> Why not? If it can do better and optimize them as well...

Well, there external. The compiler "should" not know anything about them,
and should probably not make assumptions about what the functions do. I am
wondering about something... How would a compiler know if it was ok to
reorder calls to external functions? Think if a compiler attempted to
reorder pthread_mutex_lock( ... ) and pthread_mutex_unlock() pair so that
the unlock was executed before the lock? This behavior could be dangerous,
since pthreads uses C, its theoretically broken...

.