Threads With Separate Address Spaces
Dickens Phillip
I am trying to find pointers to any research
that allows threads to have *separate* address
spaces. All of the work with which I am familiar
assumes the threads share a global address space.
If there is anyone who knows about research
with separate address spaces please send me
e-mail at pmd.icase.edu.
I will post the replies if there is sufficient
interest in me doing so.
Thanks,
Phil Dickens
Rob Pike <9764-89799> 0112710
> that allows threads to have *separate* address
> spaces. All of the work with which I am familiar
> assumes the threads share a global address space.
You might look into the idea of a process. Unix has
a system call fork() that is relevant here.
-Rob Pike
r...@research.att.com
Bodhi Mukherjee
In article <3hc5jp$4...@darkstar.UCSC.EDU>, p...@ete06-f.icase.edu (Dickens Phillip) writes:
|>
|> I am trying to find pointers to any research
|> that allows threads to have *separate* address
|> spaces. All of the work with which I am familiar
|> assumes the threads share a global address space.
|> If there is anyone who knows about research
|> with separate address spaces please send me
|> e-mail at pmd.icase.edu.
|>
I am confused .. but why should threads have
separate address spaces. If they do, aren't they
same as unix processes?
If you mean, threads having capability of having
private address spaces in addition to a shared
address space, there are some available implementations.
In fact, I think Dynix threads (created my m_fork calls)
can have private address spaces. Some Pthreads implementations
also allow you to have private threads ..
Cheers,
-- Bodhi
Larry McVoy
These are known as "processes".
Dickens Phillip (p...@ete06-f.icase.edu) wrote:
: I am trying to find pointers to any research
: Thanks,
: Phil Dickens
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Mark Everett - Sun Parallel Open Systems
In article 4...@darkstar.UCSC.EDU, p...@ete06-f.icase.edu (Dickens Phillip) writes:
>
> I am trying to find pointers to any research
> that allows threads to have *separate* address
> spaces. All of the work with which I am familiar
> assumes the threads share a global address space.
> If there is anyone who knows about research
> with separate address spaces please send me
> e-mail at pmd.icase.edu.
There is a lot of research about threads in separate
address spaces. They're called "processes". The
original UNIX used this paradigm, and stayed with it
for a very long time.
-everettm
Casey Leedom
| From: p...@ete06-f.icase.edu (Dickens Phillip)
|
| I am trying to find pointers to any research that allows threads to have
| *separate* address spaces. All of the work with which I am familiar
| assumes the threads share a global address space. If there is anyone who
| knows about research with separate address spaces please send me e-mail at
| pmd.icase.edu.
I can only assume that you want threads that have some private address
space in addition to a shared address space with the thread share group.
As several people have pointed out, threads without *any* shared address
space are usually referred to as processes.
Answering the presumed question above: yes. Under SGI's IRIX, threads can
have private regions in addition to shared regions. In fact, by default
every thread does gets a private Process Data Area (PRDA) to store things
like errno. Applications can set up similar private mappings using
MAP_PRIVATE or MAP_LOCAL in the flags parameter to mmap(). I presume that
there are other operating systems which also provide facilities like these.
Casey
David C. Brower
>In article 4...@darkstar.UCSC.EDU, p...@ete06-f.icase.edu (Dickens Phillip) writes:
>>
>> I am trying to find pointers to any research
>> that allows threads to have *separate* address
>> spaces. All of the work with which I am familiar
>> assumes the threads share a global address space.
>> If there is anyone who knows about research
>> with separate address spaces please send me
>> e-mail at pmd.icase.edu.
A bunch of people gently torched this poor guy saying he wants a
process, not a thread. Well, you might cut him an inch of slack and
consider that he might be familiar with them, and imagine what's of
potential interest.
There are many things shared between threads that are not shared among
processes. Address space is but one. The biggest, and probably most
important one is the file descriptor table, and it's state.
I can certainly imagine constructing a system that used shared fd's as
a way to balance i/o access among competing cpu resources, where the
danger of threaded programming is not desired. If you use explicitly
determined shared memory to set up queues of work between the
otherwise protected threads, you'd have some of the benefits of
threads (symmetry in the face of SMP) with reliability closer to a
non-threaded process. This is not a possibility to dismiss out of
hand.
As one noted, the Sequent magic fork does about the right thing for
variables not marked as 'shared.'
-dB
--
"Is handing over your crypto keys self-incrimination?" da...@acm.org
>> Learn about Splay Trees in "Software Solutions in C", edited by Dale <<
>> Schumacher, Academic Press Professional, ISBN 0-12-632360-7 <<
Jon Inouye
In article <3hc5jp$4...@darkstar.UCSC.EDU> p...@ete06-f.icase.edu (Dickens Phillip) writes:
>
> I am trying to find pointers to any research
>that allows threads to have *separate* address
>spaces. All of the work with which I am familiar
>assumes the threads share a global address space.
As several people have pointed out, the abstraction of one thread per
address space is known as a `process'. However, there has been a
considerable amount of research investigating fine-grain objects and
user-level processes. Both of these approaches try to maintain the
abstraction of separate address spaces per object/process while
achieving a considerable faster implementation than using separate
UNIX processes. These approaches differ from thread approach which
do not maintain the separate protection-domain/address-space
semantics of a process.
The fine-grain object approach often requires the use of a specific
language coupled with a run-time support system (see Emerald, Guide,
ORCA/Panda, and a bevy of others). The combination of protection
offered by the compiler and the run time system can often remove the
need for protection at the operating system level.
The user-level process approach attempts to bypass the (relatively)
high costs incurred by UNIX processes for local IPC, synchronization,
and context switch costs.
The MIST group at OGI is trying to remove/lessen some of these costs
in the context of running PVM applications on workstations. One aspect
of their research is to build a light-weight implementation of a PVM
task (which is usually implemented as a single UNIX process).
PVM tasks are coded in a manner where each task believes it has a
private address space. All sharing of data is performed using
message-passing. The user-level process (ULP) implementation places
all local tasks in a `single' UNIX process, but maintains the private
address space abstraction by replicating the data segment and creating
new protection domains (depends on support from OS). The user-level
process implementation allows faster message passing and context
switch times between ULPs on the same machine but maintains the
private address space semantics of a process. A paper on this
implementation appeared in SHPCC '94:
Ravi Konuru, Jeremy Casas, Steve Otto, Robert Prouty, Jonathan
Walpole, "A User-Level Process Package for PVM," in the
Proceedings of the 1994 Scalable High Performance Computing
Conference, Knoxville, Tennessee, May 23-25, 1994.
(Paper URL=ftp://cse.ogi.edu/ogipvm/papers/shpcc94.ps.gz)
(MIST URL=http://www.cse.ogi.edu/DISC/projects/mist/mist.html)
Besides the private address space abstraction, processes also have
the concept of local file descriptors, signal handlers, stdio, etc.
that need to be handled in a user-level process packages if ALL
the UNIX process functionality must be preserved.
--
Jon Inouye EMAIL: jin...@cse.ogi.edu
Distributed Systems Research Group PHONE: (503) 690-1009
Computer Science and Eng. Dept. FAX : (503) 690-1553
Oregon Graduate Institute of Science & Technology (aka OGI)
Sarr J. Blumson
David C. Brower <dbr...@us.oracle.com> wrote:
>
>There are many things shared between threads that are not shared among
>processes. Address space is but one. The biggest, and probably most
>important one is the file descriptor table, and it's state.
If memory serves, Plan 9's "fork" primitive allows you to choose
independently between copying or sharing a slew of resources, of which
the address space and file descriptors are only two.
--------
Sarr Blumson sa...@umich.edu
voice: +1 313 764 0253 home: +1 313 665 9591
CITI, University of Michigan http://www.citi.umich.edu:80/users/sarr/
Bengt Kleberg
: In article 4...@darkstar.UCSC.EDU, p...@ete06-f.icase.edu (Dickens Phillip) writes:
: >
: > I am trying to find pointers to any research
: > that allows threads to have *separate* address
: > spaces. All of the work with which I am familiar
: > assumes the threads share a global address space.
: > If there is anyone who knows about research
: > with separate address spaces please send me
: > e-mail at pmd.icase.edu.
Correct me if I'm wrong but doesn't Plan9 have the ability to
let processes share a variable amount of file descriptors,
address space and every thing?
Best Wishes, Bengt
B. Mukherjee
In article <3honvg$7...@darkstar.UCSC.EDU>, lee...@gauss.asd.sgi.com (Casey Leedom) writes:
|>
|> [stuff deleted]
|>
|> Answering the presumed question above: yes. Under SGI's IRIX, threads can
|> have private regions in addition to shared regions. In fact, by default
|> every thread does gets a private Process Data Area (PRDA) to store things
|> like errno. Applications can set up similar private mappings using
|> MAP_PRIVATE or MAP_LOCAL in the flags parameter to mmap(). I presume that
|> there are other operating systems which also provide facilities like these.
|>
|> Casey
Hi Casey:
I will like to know how does SGI implement the private space/thread. I have
used SGI threads (they provide a set of interfaces similar to Dynix) and
found them useful. However, my question is:
1. Does each thread have a private address space which is not visible to
other threads ( different page table entries)? Such an implementation
will positively improve security .. but, it will increase the context
switch time ..
2. Or, a portion of the address space is broken into several parts each
dedicated to a thread to keep private data?
Cheers,
-- Bodhi
B. Mukherjee
In article <3hoo04$7...@darkstar.UCSC.EDU>, jin...@indurain.cse.ogi.edu (Jon Inouye) writes:
|>
|> In article <3hc5jp$4...@darkstar.UCSC.EDU> p...@ete06-f.icase.edu (Dickens Phillip) writes:
|> >
|> > I am trying to find pointers to any research
|> >that allows threads to have *separate* address
|> >spaces. All of the work with which I am familiar
|> >assumes the threads share a global address space.
|>
|> As several people have pointed out, the abstraction of one thread per
|> address space is known as a `process'. However, there has been a
|> considerable amount of research investigating fine-grain objects and
|> user-level processes. Both of these approaches try to maintain the
|> abstraction of separate address spaces per object/process while
|> achieving a considerable faster implementation than using separate
|> UNIX processes. These approaches differ from thread approach which
|> do not maintain the separate protection-domain/address-space
|> semantics of a process.
|>
|> The fine-grain object approach often requires the use of a specific
|> language coupled with a run-time support system (see Emerald, Guide,
|> ORCA/Panda, and a bevy of others). The combination of protection
|> offered by the compiler and the run time system can often remove the
|> need for protection at the operating system level.
|>
|> The user-level process approach attempts to bypass the (relatively)
|> high costs incurred by UNIX processes for local IPC, synchronization,
|> and context switch costs.
|>
But, if separate address spaces are associated with each individual process,
doesn't context switch require 1. Loading of Page tables 2. TLB flushing 3. Cache
flushing and build up etc. If yes, you are just avoiding some system calls.
But, then how are you going to access page tables from user-level. I know I am
missing something here .. can you please elaborate a little on this (so that
I don't have to read the paper :-))?
Cheers,
-- Bodhi
Rob Pike <9764-89799> 0112710
In Plan 9, fork is not a system call, but a special version of the
true system call, rfork (resource fork) which has an argument
consisting of a bit vector that defines how the various resources
belonging to the parent will be transferred to the child. Rather
than having processes and threads as two distinct things in the
system, then, Plan 9 provides a general process-creation primitive
that permits the creation of processes of all weights. Processes
always have private stack and block in system calls; applications
must provide coroutine-level services in user level if they want
to, and there are examples of this including the window system
and a new concurrent programming language called Alef that
automates all this. For the record, here are the parameters to
rfork from the manual:
RFPROC If set a new process is created; otherwise changes
affect the current process.
RFNOWAIT If set, the child process will be dissociated from
the parent. Upon exit the child will leave no
Waitmsg (see wait(2)) for the parent to collect.
RFNAMEG If set, the new process inherits a copy of the
parent's name space; otherwise the new process
shares the parent's name space. The tag space for
rendezvous(2) is considered part of the name
space. Is mutually exclusive with RFCNAMEG.
RFCNAMEG If set, the new process starts with a clean name
space. A new name space must be built from a mount
of an open file descriptor. Is mutually exclusive
with RFNAMEG.
RFENVG If set, the environment variables are copied; oth-
erwise the two processes share environment vari-
ables. Is mutually exclusive with RFCENVG.
RFCENVG If set, the new process starts with an empty envi-
ronment. Is mutually exclusive with RFENVG.
RFNOTEG Each process is a member of a group of processes
that all receive notes when a note is written to
any of their notepg files (see proc(3)). The
group of a new process is by default the same as
its parent, but if RFNOTEG is set (regardless of
RFPROC), the process becomes the first in a new
group, isolated from previous processes.
(Notes are analogous to signals; RFNOTEG is analogous
to the idea of a controlling tty.).
RFFDG If set, the invoker's file descriptor table (see
intro(2)) is copied; otherwise the two processes
share a single table.
RFCFDG If set, the new process starts with a clean file
descriptor table. Is mutually exclusive with
RFFDG.
RFMEM If set, the kernel will mark segments of type data
and bss as shared. The child will then inherit all
the shared segments the parent process owns. Other
segment types will be unaffected. Subsequent
forks by the parent will then propagate the shared
data and bss between children. The stack segment
is always split. May be set only with RFPROC.
Two observations: first, RFPROC is not automatically on, so processes
can change their own properties relative to others, for example to
make their name space private; second, if you were to grep for all
uses of rfork, you'd find that the combinations are many and that
it would be hard to find two programs that use the same set of
bits in their call to rfork. This latter point validates our claim
that it is better to have a general process creation mechanism than
a special kind of `lightweight' process.
-Rob Pike
r...@research.att.com
Jonathan Shapiro
Phillip) writes:
> I am trying to find pointers to any research
>that allows threads to have *separate* address
>spaces. All of the work with which I am familiar
>assumes the threads share a global address space.
EROS and KeyKOS both provide variable weight threads. In these systems,
the closest analog to a process is called a domain. A domain contains a
set of user level registers, up to 16 capabilities (called "key
registers"), a meter (keykos) or schedule (eros) capability and an
address space segment capability. Holding a capability conveys
authority to use a resource. There is no other mechanism for obtaining
such authority at the OS level.
To construct conventional threads one simply creates two domains and
gives them the same address space capability. If more than 16
capabilities are required (rare), or a pool of capabilities needs to be
shared, KeyKOS and EROS support an object called a "node" that holds
more capabilities. If the two threads both hold a capablity to such a
node, they can both access it's contents.
So on to your question about "quasi-threads":
KeyKOS and EROS Segments are tree-structured and hierarchically
composable. Getting away from fancy words this means that two processes
can share an arbitrary portion of their data, possibly (but not
necessarily) at the same virtual address. If the virtual addresses are
suitably chosen, KeyKOS (and EROS eventually - just not there yet) will
even share page tables.
The end result is that memory resources and authority can be shared in
pretty much any way you want.
What it sounds like *you* want is the ability to build to processes that
share a subset of their address space and also have private storage.
This is possible in EROS and KeyKOS, and in most UNIX systems (take a
look at the mmap(2) system call, or the shared memory calls in SysV).
More information on EROS and KeyKOS can be obtained via the web if you
start from my home page:
http://www.cis.upenn.edu/~shap/home.html
Being able to share resources in essentially arbitrary ways is a good
thing. In part, it helps defeat the myth that threads v/s processes is
the issue of interest. The real issues are "what resources are shared"
and "how much do private resources cost."
Two domains that do not share a complete address space must suffer with
flushing the TLB (and on some machines the cache). There is a commonly
held belief that avoiding the TLB flush significantly improves thread
performance.
In practice, I'm skeptical. On a lightly loaded system, threads
definitely win, but unless your process scheduling algorithm has been
carefully designed to take advantage of threads, it is unlikely that
threads will share TLB entries in practice on a heavily loaded system.
Today's TLB's are simply too small, and the number of things that
interrupt processes (including the kernel) are too large. Heavy loads
tend to defeat even the smartest thread schedulers.
Also, the performance distinction is likely to go away as processors get
smarter. More and more processors are adopting some form of address
space identifier register, which makes the TLB flush unnecessary.
None of this is an argument against threads! Having multiple control
flows in a single address space is a very useful abstraction. But
depending on the performance advantage seems unwise. The underlying
advantage won't last (processes are catching up), and even on today's
machines it scales badly under load.
Jonathan S. Shapiro
Anders Lindstrom
lee...@gauss.asd.sgi.com (Casey Leedom) writes:
We have just finished writing a paper that describes the model of address
space management used in the Grasshopper operating system. It also allows
you to do the equivalent of a thread-private mapping. It actually lets you
do a whole lot of other stuff as well but you'll have to read the paper
for that. In some ways, our philosophy on sharing of the address space is
very similar to Plan 9s. We only have one abstraction of computation rather
than two (processes and threads) and allow user-level software to choose
what bits of an address space are shared between what threads (they're not
called this in Grasshopper but they are roughly analogous).
The paper will appear in the upcoming 5th Workshop on Hot Topics in Operating
Systems (HotOS-V) in May. It is available via ftp from:
ftp.gh.cs.su.oz.au/pub/gh/reports/GH-11.ps.Z
or from our WWW page:
http://www.gh.cs.su.oz.au/Grasshopper/Papers/index.html
Anders.
- --
Anders Lindstrom Phone: +61 2 692 4174
Basser Department of Computer Science Fax: +61 2 692 3838
Madsen Building F09
University of Sydney NSW 2006
Australia
WWW: http://www.gh.cs.usyd.edu.au/~anders/index.html
------- End of Forwarded Message