rcbc@honir.cs.cornell.edu (Robert Cooper) (11/13/89)
There is no intrinsic limit to the number of simultaneous lightweight tasks
in an ISIS program. However you will eventually run out of virtual memory.
Each task is allocated a new stack which is usually 32Kbytes by default,
and you can change this using t_set_stacksize. Also, ISIS tasks are
implemented using whatever threads package is available on the
machine/operating system you are running on, and this threads mechanism may
impose some limit of its own. Some thread mechanisms have variable stack
sizes---you only use as much as you need---while others provide no way to
change the default stack size.
So exactly how many ISIS tasks you can create depends on the system
you are running. You are best to experimentally determine how many
tasks you can create before some resource is exhausted.
In practice we use many tens of tasks in our programs, but probably not
hundreds.
-- Robert Cooperken@gvax.cs.cornell.edu (Ken Birman) (11/13/89)
In article <34156@cornell.UUCP> rcbc@honir.cs.cornell.edu (Robert Cooper) writes: >There is no intrinsic limit to the number of simultaneous lightweight tasks >in an ISIS program. However you will eventually run out of virtual memory. > Just to follow through on this thought, in our own code we always avoid creating large numbers of tasks. The virtual memory thrashing that starts to occur after around 30-40 tasks is just not worth the simplicity such a solution yields, and even under a system like Mach (which has a better pager) large numbers of tasks still cost too much to tolerate. I almost always find that there is a way to solve this type of problem by packing multiple messages into a single bigger one (the message analogy to "buffered output"). See clib/cl_join.c for example: xfer_out() does this. Another approach is to use _non_blocking_ tasks to receive the incoming messages. Since they don't block, you are conceptually using a large number of tasks, but at any point in time only one will be active. (Warning: if a task DOES block, keep in mind that almost anything can happen while it is sleeping: processes can fail, etc...) Tasks block by (1) doing ISIS system calls, or (2) by calling t_wait(). Ken
tc@oxtrap.sendai.ann-arbor.mi.us (Tse Chih Chao) (11/14/89)
In article <34162@cornell.UUCP> ken@gvax.cs.cornell.edu (Ken Birman) writes:
(Warning: if a task DOES block, keep in mind that almost anything can
happen while it is sleeping: processes can fail, etc...) Tasks block by
(1) doing ISIS system calls, or (2) by calling t_wait().
Man pages of t_wait() is wrong.ken@gvax.cs.cornell.edu (Ken Birman) (11/15/89)
In article <TC.89Nov14144511@oxtrap.sendai.ann-arbor.mi.us> tc@oxtrap.sendai.ann-arbor.mi.us (Tse Chih Chao) writes: > .... Man pages of t_wait() are wrong. I reread the online man page for t_wait and also the relevant sections of the ISIS manual. I can't find anything wrong.
tc@oxtrap.sendai.ann-arbor.mi.us (Tse Chih Chao) (11/15/89)
In article <34238@cornell.UUCP> ken@gvax.cs.cornell.edu (Ken Birman) writes:
I reread the online man page for t_wait and also the relevant
sections of the ISIS manual. I can't find anything wrong.
The version we have is V1.3.1 and the man pages for both t_wait and isis_init
are identical. These man pages talk about the replying and forwarding
the messages and they are incomplete. SOunds like we have an older
version of man pages.