Re: Self-scheduling threading
Re: Self-scheduling threading
- Subject: Re: Self-scheduling threading
- From: Michael Koehmstedt <email@hidden>
- Date: Thu, 17 Mar 2005 14:25:01 -0800
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.
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.
Michael Koehmstedt
On Thu, 17 Mar 2005 17:04:54 -0500, Bob Ippolito <email@hidden> wrote:
>
> On Mar 17, 2005, at 16:43, Michael Koehmstedt wrote:
>
> > On Thu, 17 Mar 2005 07:15:35 -0800, Shawn Erickson
> > <email@hidden> wrote:
> >>
> >> On Mar 17, 2005, at 2:06 AM, Michael Koehmstedt wrote:
> >>
> >>> I need to be able to break up each thread's timeslice into explicitly
> >>> schedule mini-threads. Basically exactly like fibers on a win32
> >>> system.
> >> [snip]
> >>> If there is sufficient interest by other community members, I'd like
> >>> to create an open-source Objective-C framework for this kind of
> >>> threading model. Whether it means porting an existing C/C++
> >>> implementation or a new one, I'm up for whatever. I just want a
> >>> solution that's efficient and features an extremely simple
> >>> explicitly-scheduled threading model.
> >>
> >> Do you really know that their are noticeable gains to be made
> >> especially given the work it would take?
> >>
> >> (can depend greatly on the number of would be blocking calls that you
> >> are trying to have going in parallel)
> >>
> > If you were in my position, which solution would you look for? I
> > wouldn't mind using the simplest solution, as long as the performance
> > is acceptable.
>
> You still haven't stated what you plan to gain by using explicitly
> scheduled threads rather than pre-emptive OS scheduled threads.
> Chances are, OS threads are fine, and this premature optimization
> (explicitly scheduled threads) is potentially (probably) not an
> optimization at all in the first place.
>
> -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