Thread performance (was Re: dynamic context transitions)

[John E. Malmberg]

Christopher R. Hertel wrote:
> 
> So, in the context in which we are generally working, I see that it is 
> provable that threads are slower than processes.  No problem.  I see your 
> logic and it makes perfect sense to me.

It is provable in some cases either way.

For memory and resource protection, and protection from software bugs, 
separate processes are going to be better.

Posix Threads have another disadvantage that has not yet been mentioned. 
  Limited stack space as compared to the process model.

This limited stack space puts a limit on the scaling of the Posix Thread 
based solution, unless other tricks are used.

The process based model also will put some limits on the scaling of the 
software for a specific machine.

Note that Microsoft does not appear to use either a Posix Thread 
environment or a per-process environment as near as can be determined by 
looking at their systems with the monitoring tools provided by them.

> The game I am playing in my mind is one of turning the constants into
> variables to see what happens.  The definition of a "proccess" and a
> "thread" has changed over time.  So have CPUs and Operating Systems.  All
> of those things are variables.
> 
> This excercise probably doesn't have much practical value.  I'm okay with 
> that.  I've got plenty of practical things to do.  :)  My brain gets tired 
> of practical things some times and I just like to "think" a bit to see 
> what else occurs to me.

It may have a practical value.  Both Posix threads and processes have 
overhead that it may be desirable to avoid.

An asynchronous I/O model allows you to write code using a threaded 
model, yet does not have the overhead of either the process model or the 
Posix thread model.

Both the Posix Thread model and the asynchronous I/O model have the 
security issue with SAMBA as SAMBA has to have the security context of 
the sending process.

OpenVMS Alpha and IA64 for version 7.3 and later allow setting the 
security context on a per thread basis.

> I'm working under the assumption that there are alternate configurations
> in which using threads would be faster than using processes.  I'm trying
> to figure out what would need to change to make that the case.  Possibly
> the definition of a process, possibly the definition of a thread, possibly
> the underlying assumptions built into the OS, and possibly the kinds of
> things you would do with threads when writing an application.  Maybe some
> of each.  There's really no harm in considering the problem...

Look at the AST model in OpenVMS.  An AST is like a software interrupt.

With a AST behaving like a software interrupt, it solves some of the 
"synchronization" problems, as only one of them can be active for a 
process at once.  It also means that you do not want any AST to be in a 
wait state.

When an asynchronous I/O is posted on OpenVMS through the native I/O 
system, it also has the address of a completion AST, which it passes an 
argument for so that the completion function knows the context.

By stringing these ASTs along from an origination point such as a task 
dispatcher you can build a threaded application with out the overhead or 
the stack limitation of Posix threads.

It still does not solve all security issues that have been mentioned, it 
has improved scaling over both the Posix Thread model and the per 
process model.

Such a solution generally does not result in portable code.  Finding a 
way to implement it portably on the various UNIX platforms could be a 
challenge.

-John
wb8tyw at qsl.net
Personal Opinion Only