|
Home > Archive > Unix Programming > December 2006 > Imp: shared memory
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Imp: shared memory
|
|
| shaanxxx 2006-12-19, 1:31 am |
| Is shared memory is part of kernel space ?
http://en.wikipedia.org/wiki/Userspace
The way wikipedia has defined, shared memory is always part of user
space. Correct me ,if I am wrong.
Although, shared memory has kernel persistent. We always map it to user
space. That is why we can access that shared memory without going into
kernel.
Any comment on this would be appreciated.
Thanks
| |
| Jens Thoms Toerring 2006-12-19, 7:32 am |
| shaanxxx <shaanxxx@yahoo.com> wrote:
> Is shared memory is part of kernel space ?
Yes.
> http://en.wikipedia.org/wiki/Userspace
> The way wikipedia has defined, shared memory is always part of user
> space. Correct me ,if I am wrong.
I can't see where you read this. Is it the sentence "A user application
cannot access kernel space directly..."?
> Although, shared memory has kernel persistent. We always map it to user
> space. That is why we can access that shared memory without going into
> kernel.
But you're going through the kernel when you attach to the shared memory.
E.g. shmat() _is_ a system call, that (if the kernel likes you and you
ask it nicely;-) maps the shared memory region into user space. So you
can't use it "directly" but need the kernel to make it accessible, i.e.
open a window to (a restricted region of) kernel space.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
| |
| Rainer Weikusat 2006-12-19, 1:23 pm |
| jt@toerring.de (Jens Thoms Toerring) writes:
> shaanxxx <shaanxxx@yahoo.com> wrote:
>
> Yes.
Why this?
[...]
>
> But you're going through the kernel when you attach to the shared memory.
> E.g. shmat() _is_ a system call, that (if the kernel likes you and you
> ask it nicely;-) maps the shared memory region into user space. So you
> can't use it "directly" but need the kernel to make it accessible, i.e.
> open a window to (a restricted region of) kernel space.
I don't think this is a sensible description. If you attach to a
shared memory segment or if you map one via mmap, the page tables of
the process doing so need to be modified appropriatley and this can
only be done by the kernel because it is a priviledged operation
(technically, modifing the table is usually not, but the memory
containing them will not be modifiable by the process). But this
creates a new virtual mapping in the process address space which
doesn't necessarily correspond with anything in the kernel address
space.
| |
| Jens Thoms Toerring 2006-12-19, 1:23 pm |
| Rainer Weikusat <rainer.weikusat@sncag.com> wrote:
> jt@toerring.de (Jens Thoms Toerring) writes:
[vbcol=seagreen]
> Why this?
You're right - the memory is in user space memory. What I wanted
to express is that it does not belongs to a user-land process but
to the kernel that takes care of it and makes sure that it's not
"going away" when no process is attached to it (unless explicitely
asked to).
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
| |
| shaanxxx 2006-12-21, 1:29 am |
| Thanks jens and Rainer.
Got the anwer
Jens Thoms Toerring wrote:
> Rainer Weikusat <rainer.weikusat@sncag.com> wrote:
>
>
> You're right - the memory is in user space memory. What I wanted
> to express is that it does not belongs to a user-land process but
> to the kernel that takes care of it and makes sure that it's not
> "going away" when no process is attached to it (unless explicitely
> asked to).
> Regards, Jens
> --
> \ Jens Thoms Toerring ___ jt@toerring.de
> \__________________________ http://toerring.de
| |
| shaanxxx 2006-12-21, 1:29 am |
|
Jens Thoms Toerring wrote:
> shaanxxx <shaanxxx@yahoo.com> wrote:
>
> Yes.
>
>
>
> I can't see where you read this. Is it the sentence "A user application
> cannot access kernel space directly..."?
>
An operating system usually segregates virtual memory into kernel space
and user space. Kernel space is strictly reserved for running the
kernel, device drivers and kernel extensions
>
> But you're going through the kernel when you attach to the shared memory.
> E.g. shmat() _is_ a system call, that (if the kernel likes you and you
> ask it nicely;-) maps the shared memory region into user space. So you
> can't use it "directly" but need the kernel to make it accessible, i.e.
> open a window to (a restricted region of) kernel space.
Actually i wanted to ask : Once shared memory is mapped, there is no
involvement of kernel when we access shared memory? I meant no special
treatment for share memory access.
thanks
Shaan
>
> Regards, Jens
> --
> \ Jens Thoms Toerring ___ jt@toerring.de
> \__________________________ http://toerring.de
| |
| Jens Thoms Toerring 2006-12-22, 1:17 pm |
| shaanxxx <shaanxxx@yahoo.com> wrote:
> Actually i wanted to ask : Once shared memory is mapped, there is no
> involvement of kernel when we access shared memory?
That's right. Once it's mapped into the processes address space
it's like all other "normal" memory, i.e. the kernel doesn't has
to do any special translations or anything else differing form
what it has to do for normal memory. That makes shared memory a
rather fast method of IPC (in contrast to e.g. messages where
each message has to be send via a system call and retrieved
by another system call).
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
|
|
|
|
|