Re: shared memory between processes

From: Peter T. Breuer (ptb_at_lab.it.uc3m.es)
Date: 05/05/05 

Date: Thu, 5 May 2005 19:38:57 +0200

Todd Knarr <tknarr@silverglass.org> wrote:
> In comp.os.linux.development.system <d5datj$o8k$1@zcars129.ca.nortel.com> Chris Friesen <cfriesen@nortelnetworks.com> wrote:
> > Todd Knarr wrote:

> >> int iGlobalStatus = 0;
> >> int bTerminate = 0;
> >>
> >> // Thread A
> >> void threadAFunc()
> >> {
> >> while ( !bTerminate )
> >> sleep( 10 );
> >> pthread_exit( &iGlobalStatus );
> >> }
> >>
> >> // Thread B
> >> void threadBFunc()
> >> {
> >> sleep( 60 );
> >> bTerminate = 1;
> >> pthread_ext( &iGlobalStatus );
> >> }

> > Okay, now put a mutex around accesses to "bTerminate". Problem goes
> > away. Dave Butenhof has gone on at length about this.

> From experience, merely putting mutexes around it doesn't help, because
> in thread A the optimizer can still put bTerminate's initial value in
> a register and then refer to the register, not the memory location,
> when doing the loop test.

This is half-correct. The lock would merely guarrantee atomic access to the
variable. However I don't believe the compiler ever has a right to
optimize away an exportable global! If you declared the variable
static, and the two functions too, then it would at least be valid in
theory (though I doubt that any compiler would do such an optimisation,
since it is optimisation across different compilation units -
functions).

But atomic access to the variable is guaranteed anyway, since it is a
(32-bit) single variable and the accesses are unique reads and writes.
I don't know if the 32-bitness matters, comes to that, since we're in
userspace (feel free to comment). Are you worrying about the reordering
of the statements in the generated machine code? I.e. that we need to
insert memory barriers into the assembler? Surely that's what
"volatile" does, no? (I haven't checked the assembler output).

> > Making it "volatile" is *not* guaranteed to be sufficient across
> > multiple CPUs on all architectures. I believe it would fail on Alpha,
> > for instance.

> Exactly. You need to make it volatile _and_ mutex it to insure both
> interlock and that the optimizer never removes the reference to the
> actual memory location. Or you need to make it volatile and use an

What? Beg pardon? Come again?

What do you mean by "reference to the actual memory location"? All
global variables are references to memory locations - that's the point!

> access method (for example specially-written in-line assembly code)
> that guarantees hardware-level-atomic access (which is how I ended
> up solving it since it's an order of magnitude less overhead than
> a mutex lock/unlock call pair and I had places where I was doing
> several thousand of these operations a second and even small overheads
> added up fast).

Would you mind explaining a little? I suspect you are talking about
hand-crafted assembler.

Peter

Relevant Pages

  • Re: shared memory between processes
    ... > interlock and that the optimizer never removes the reference to the ... > actual memory location. ... not sufficient and the use of 'volatile' was required to share memory. ...
    (comp.os.linux.development.system)
  • Re: [EGN] Hoisting Loop Invariants (Was: Re: [EGN] Numerical Accuracy)
    ... >> circumvent the automatic optimizer have as their purpose vanity alone. ... > While this may be true of certain practices, hoisting loop invariants is ... the programmer has this knowledge, then the programmer should not use ... >> this scenario is the fact that the function uses a REFERENCE parameter ...
    (comp.programming)
  • Re: [Clax86list] Optimizing Static Variable Layout
    ... > The ability of the assembler to preserve the programmer's desired ... possible, by moving declarations around. ... We are talking about HLA syntax here. ... > rather than as an "optimizer". ...
    (comp.lang.asm.x86)
  • Re: Linux without the GNU toolchain?
    ... We did have an assembler which I used to bootstrap everything. ... We also had a FORTRAN compiler that generated code incompatible with the ... that if the optimizer noticed it was in trouble, it would just exit and pass ... Once expanded inline, I moved ALL the instructions from the loop, so they ...
    (comp.os.linux.misc)
  • Re: Now rather OT: Assembler etc... [Was Re: Put out to Pasture ?]
    ... Checkout compiler in 1970. ... Although the Optimizer and Checker obviously recycled the three-letter prefixes IEL and IEN that had once been allocated to the PL/I and compilers. ... while it has an 'H' in the acronym is actually the "High Level Assembler" not an 'H-Level' Assembler. ...
    (comp.lang.pl1)