Gustav Schaffter wrote:
> Interesting thoughts about context switching. But, correct me if I'm
> wrong, I guess that in a multi processor environment, this may be quite
> complicated since two (or more) threads are *really* executed in
> parallel. Right?
Well, maybe, but you can't know about that. I remember on the old Tandem
multiprocessor boxes that we had to actually tell non-stop processes which
processor they were to use, checkpoint events, etc.
Threads are different. I don't know--and I'm dead certain that there are
folk who will cheerfully and quickly inform me--if there are any thread
libraries that let (or force) you to worry about multi-processor thread
assignment. I do know that in many implementations the thread manages its
own prioritization and execution *within that of the process*. That is,
you may have multiple threads, but nothing can acquire clock ticks beyond
those of the process; each thread shares with other threads within the
execution allocation of the parent process.
I don't know if anyone has done anything cool with SMP, in Linux or any
other Unix, to allow a library routine (or, by extension, any function)
in user space to indicate either what processor it wants to use, or
that it can be assigned to a separate processor as a thread of
execution. I don't see it in the online docs, but I'm not in a
position right now to do a web search.
In the normal course of things, in any case, you'll program your
threads with respect to their own critical regions and dependencies.
If the library can, it'll do assignment to individual processors with
aid of the OS; if not, then so. You've got portable code, and
depending on the services offered by the OS, you will or won't get the
efficiencies of thread distribution across processors.
Cheers,
--
Dave Ihnat
[EMAIL PROTECTED]
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
