[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ast-users
Subject:    Re: [ast-users] RE: Multiple threads in ksh
From:       Roland Mainz <roland.mainz () nrubsig ! org>
Date:       2008-10-09 12:15:56
Message-ID: 48EDF5FC.E5CC2C96 () nrubsig ! org
[Download RAW message or body]

Janis Papanagnou wrote:
> > Andrew Clarke wrote:
> >> On Thu, 09 Oct 2008 00:36, I. Szczesniak wrote:
> >>> On 9/29/08, David Korn  wrote:
> >>>> Subject: Re: ksh93t and version numbering (Was Re: [ast-users] ksh93t
> >>>> 2008-09-26 beta src) If I make a version that works with multiple
> >>>> threads, then it would become a new version like 'u'.
> >>>
> >>> Supporting multiple threads would be a feature which would be greatly
> >>> appreciated.
> >>
> >> Ummmm, that's called "pipelines" and "co-processes" isn't it?
> >
> > No, that are seperate "processes". The idea David was talking about is
> > to allow multiple execution threads in one process - the threads all
> > share the shell's global variables but have private local variables
> > which they can use for parallel processing.
> 
> If it's for the common variables one could think of encapsulating shared
> memory access, tied to the export and/or typeset command.
> 
> The problem with another "light weight process" concept in addition to
> processes is that you'd probably need to duplicate all the process
> synchronization mechanisms.
> 
> One/the main advantage of threads was said to be execution speed, to avoid
> process context switches.  Now if it's just for the variables name space
> there are less intrusive possibilities, I suppose.

It's not about sharing variables, it is about syncronisation (which
includes both locking and "barriers"), shared access to file
descriptors, thread control (e.g. thread scheduling priority, signal
handling, thread cancelation) etc. too. And even sharing variables
between _processes_ would a _pain_ to implement in a reasonable fast way
and doing that for whole compound variable trees would even be a greater
issue.

Just for the log: 
We've considered the following alternatives to threads sharing
variables:
- |mmap()| - which provides no portable way for locking, rounds memory
usage up to the system's default pagesize
- Use SystemV shared memory - not portable, no fast way for locking,
number of shared memory segments are restricted, does not scale
- Use files - slow, file locking unreliable over NFSv2/NFSv3 and other
"uncommon" filesystems such as Fuse
... and there are more issues, for example signal handling (wbere the
POSIX threads API has a good solution)

After all using the POSIX thread API looks the best and flexible way to
handle intended features in a portable and scaleable way (scaleable
means that this should still run efficiently with 2048 threads per
process - see
http://www.theregister.co.uk/2007/07/26/sun_2048_thread_niagara/ for the
article about the low-end/midrange machines we'll face at the end of
this decade).

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)
_______________________________________________
ast-users mailing list
ast-users@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-users
[prev in list] [next in list] [prev in thread] [next in thread]