Re: Self-scheduling threading
Re: Self-scheduling threading
- Subject: Re: Self-scheduling threading
- From: Bob Ippolito <email@hidden>
- Date: Thu, 17 Mar 2005 18:43:57 -0500
On Mar 17, 2005, at 6:22 PM, Michael Koehmstedt wrote:
On Thu, 17 Mar 2005 17:44:58 -0500, Bob Ippolito <email@hidden>
wrote:
On Mar 17, 2005, at 17:25, Michael Koehmstedt wrote:
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.
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.
The result will be that developers can focus on the logic of their
application, and not have to worry about the underlying mechanisms.
Safe, efficient multithreading is not a trivial thing to add to any
application, and it is (or should be) completely separate from the
application's logic. That is what this framework is doing: providing
numerous underlying mechanisms, all tied closely together so that the
application developer can focus on what's really important for the
application and not have to reinvent the wheel every time.
That is what I plan to gain by using explicitly scheduled fibers. It
is not a premature optimization, but a design choice.
Without using a whole heck of a lot of magic macros, and/or some truly
evil C stack slicing, I'm really not sure that what you're trying to
do
is even reasonable for Objective-C.
A sane solution with the Least Magic Used would look just like what
you
already have in Foundation: a reactor (NSRunLoop), event sources
(NSTimer, etc.), and event sinks (usually targets of the sources).
There are certainly improvements that can be made there, though.
In most event driven systems I've ever seen, you've got very few
things
Doing Work in every iteration of the run loop, so you've just got a
bunch of sinks waiting for something to happen. When stuff does
happen, round-robin works rather well. Time slicing is probably
overkill, you can't pre-empt anyway. This is again basically what
NSRunLoop/CFRunLoop does.
What do you want to do that's any different/better than what's already
there?
I don't know
I am rather new to Cocoa development and unsure of its capabilities.
So if Cocoa can allow me to pause my thread's execution and restart at
a previously paused point (for resuming blocked IPCs/RPCs) without
resorting to the creation of extra threads, then I'd be happy to use
it because I'm sure it'd also provide the simplest solution as well.
What I'm saying is that there is no pause in C or Objective-C. Going
from one function to another can only cause the stack can to go up or
down, not sideways -- unless you do nasty, horrible things that would
probably break exceptions really really badly among other things.
If I understand you correctly, the only way to achieve the effect you
desire is to write your program in continuation passing style or make
it callback driven (basically the same thing). There is no pause, only
return. You can pause an OS thread (well, make it wait), but you don't
want to have a lot of those.
In short, what you seem to want is really not something you can have.
Given that C or Objective-C has no sensible concept of nested
functions, closures, etc. writing event driven code is going to be
tedious any way you slice it. NSInvocation might relieve the burden
ever so slightly, but not by much.
-bob
_______________________________________________
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