Re: shared memory between processes
From: Peter T. Breuer (ptb_at_lab.it.uc3m.es)
Date: 05/04/05
- Next message: Peter T. Breuer: "Re: shared memory between processes"
- Previous message: Robert Redelmeier: "Re: Memory testing in a kernel thread"
- In reply to: Kasper Dupont: "Re: shared memory between processes"
- Next in thread: Chris Friesen: "Re: shared memory between processes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Next message: Peter T. Breuer: "Re: shared memory between processes"
- Previous message: Robert Redelmeier: "Re: Memory testing in a kernel thread"
- In reply to: Kasper Dupont: "Re: shared memory between processes"
- Next in thread: Chris Friesen: "Re: shared memory between processes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|