[OT] Re: Self-scheduling threading
[OT] Re: Self-scheduling threading
- Subject: [OT] Re: Self-scheduling threading
- From: Shawn Erickson <email@hidden>
- Date: Thu, 17 Mar 2005 15:25:09 -0800
On Mar 17, 2005, at 2:25 PM, Michael Koehmstedt wrote:
Bob,
My framework has no need of OS scheduled-threads. There will only be
one thread per processor, so that no thread scheduling is done at all,
really. However, I need to be able to manage the time slices of these
threads, for efficient use of event-driven IPC/RPC.
What do you mean by time slices?
Saying that can imply you want preemption? If not preemption then what
do you mean?
Without preemption you are talking about cooperative "threading" of
some type, in other words a unit of work (likely a small part in a
larger body of work) has to be short enough in duration to run then
yield time to the other work units that want CPU time and the duration
likely depends on responsiveness goal for user interaction or external
system interaction.
So I think you are talking about a framework to help define a work unit
(what it does, what responsive it may need, etc.), provide a way to
execute work units based on some logic on who should run next. Right?
You say in the above that you want to support at least one thread per
CPU so do you plan to prevent two interdependent work units from
executing concurrently? Provide ways for an interlock between
interdependent work units, etc.?
Who do you see using this type of framework? What type of products? To
be honest it still isn't clear what problem space you are trying to
solve or help solve (or at least a prevalent enough of one).
The framework is intended to, among other things, promote the use of a
certain kind of design pattern in order to eliminate or heavily reduce
the traditionally most expensive operations of a multi-threaded
application: context switching and lock contention.
As I said before you may want write some test applications and Shark
them to see how much of issue context switching and lock contention
really is. Sure you can code something that will fall performance wise
if you want but most software is better written (or can be).
Anyway to keep this on topic some what the Cocoa list some of what you
are talking about, at least from an event driven perspective is
supported and utilized by NSApplication based application or
applications using things like NSRunLoop/CRRunLoop directly. This
allows for a single thread to serially process items of work in
response to incoming events (can by from the user, network, timers,
etc.).
IOKit also has the runloop concept in the form of IOWorkLoop and one of
the reasons it explicitly exists is to avoid context switching across a
stack of objects not directly related to each other or even provided by
the same vendor (for example allows a current thread to muck with say a
drivers state without having to switch to a thread directly owned by
that driver and does so in a thread safe way, only one thread is
allowed to be inside the gate of a given IOWorkLoop instance at a
time).
-Shawn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden