Re: shared memory between processes

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


Date: Wed, 4 May 2005 22:36:55 +0200

Kasper Dupont <kasperd@daimi.au.dk> wrote:
> "Peter T. Breuer" wrote:
> >
> > Because automatic variables are not shared, since the stack is not
> > shared between threads - it would cause chaos if it were!

> Depends on what you mean by shared. The stacks are in
> shared memory (there is really no other possibility

I don't follow - man clone(2) for example:

    The child_stack argument specifies the location of the stack used by
    the child process. Since the child and parent processes may share
    memory, it is not possible in general for the child process to
    execute in the same stack as the parent process. The parent process
    must therefore set up memory space for the child stack and pass a
    pointer to this space to __clone.

That's what happens. Threads in any sense I have heard of do not
*share* stack space. As to whether the spaces are inter-accessible via
some sleight-of-hand, I really can't say. It somewhat looks as though
they are, in principle, from that manual entry. Strange. I would have
thought they divorced more thoroughly.
    
   
> since threads by definition share the entiry address > space). But
each thread have its own stack on a seperate > address.

Yes.

> That doesn't mean they can't access variables
> on another thread's stack.

Well, that depends on what happens after clone. I guess one could
somehow mark the new stack as inaccessible to the parent, by some weird
syscall that does some remapping. I know nothing about the
implementation of pthreads! I was simply pointing out that threads do
not share the same stack, hence automatic variables do not need to be
declared volatile.

> Did you ever look how the kernel implements waiting on
> runqueues?

Ummm ... I think so. But obviously not at the level of the
implementation you are thinking of.

> It is a good example of why it makes sense
> to access a variable on the stack of another thread. A
> local struct is linked into a global data structure
> (and of course it is removed again before the function
> terminates).

> > Do you have different kinds of threads than I do!

> No, but maybe you don't understand how they work.

Oh, I understand their algebra - I am not interested in the
implementation, of course.

> > They are. Programming with monitors is equivalent to programming
> > with semaphores.

> Yes, but declaring a variable as volatile has
> nothing to do with monitors.

Probably!

Peter



Relevant Pages

  • Re: stack and heap
    ... Automatic variables behave in the way you'd expect if they were placed ... and destroyed when that scope is exited, and no scope can be exited until ... something called a "stack". ... Dynamically allocated memory does not have ...
    (comp.lang.c)
  • Re: If Macs have no spyware....
    ... >had made a complete code review of its operating system and removed all ... and writing new data into those memory locations would ... >but when the data exists on the stack, it can cause very large problems. ... >location that needs to be written in place of the correct execution ...
    (comp.sys.mac.advocacy)
  • Re: If Macs have no spyware....
    ... First you yammer about being a Mac advocate, then bad mouth me for dumping XP in favor of a Mac. ... Supposedly Microsoft had made a complete code review of its operating system and removed all the buffers which could overflow. ... the fundamental problem is that the basic architecture of Windows has two fatal flaws in its memory management and while these remain in the software the ad hoc patches will never be enough to make Windows a secure operating system. ... These problems are bad enough when dealing with data in the one routine but when the data exists on the stack, it can cause very large problems. ...
    (comp.sys.mac.advocacy)
  • Re: Maybe we should stop "Paging Beth Stone" already...
    ... I'll want to work on my OS while running my OS, so the assembler that it's written with has to run under it. ... You have to swap CR3 if you want seperate memory spaces. ... The alternate stacks aren't used by the processor unless the task calls a different protection level, so they're not part of the TSS swap. ... This lets any application use up to a gigabyte of stack before Linux is forced to tell it that it's gone too far. ...
    (alt.lang.asm)
  • Re: When is "volatile" used instead of "lock" ?
    ... to get the address of a stack variable to a background thread. ... I'm suggesting that the memory model ... lock pattern works without making the instance member volatile; ... fields shared amongst more than one thread despite following the locking ...
    (microsoft.public.dotnet.languages.csharp)