On 08/02/2008, Andreas Raab <andreas.raab at gmx.de> wrote:
> Igor Stasenko wrote:
> > Well, i expect that your potential scheduler gives a chance to run
> > processes at _any_ priority (doing something sometimes to switch
> > active processes). Otherwise we're in not the parallel domain anymore.
>
> Ah. Now we're starting with assumptions ;-)

Not really, as i said, if you claim that your scheduler able to run
two (or more) parallel processes, it should be true. Otherwise, i
can't call it a scheduler of parallel processes :)

>
> > If you want , at some point to get all results filled, you can use
> > Semaphore, or plain counter (just make sure you get in to ABA mess
> > with it):
> >
> > sema := Semaphore new.
> >  1 to: 5 do:[:i|
> >     [ i == 1 ifFalse: [ [ (result at: i-1)  isNil ] whileTrue: [] ].
> >      result at: i put: i. sema signal ] forkAt: Processor
> > activePriority - 10 + i.
> > ].
> >
> > [ sema excessSignals < 5 ] whileTrue: [].
> > <here you got your array filled>
>
> That's a little better. Still not good enough though. Now let's assume
> that my theoretical scheduler has limits for how many threads it can
> have scheduled at the same time (because of memory limits, cores etc).
> Not unusal at all. Would you like to try again?
>

Hmm, do you want me to change the code because scheduler can't handle
problem itself?
That is exactly what i'm against: there should be API, which gives me
a feeling that my tasks are running in parallel, no matter what it's
doing inside.
My code should not depend from it: my task is to write concurrent
program, a scheduler task is to make it possible :)
Isn't low level implementation serves to reach higher level of
abstraction, allowing programmer to write code without deep knowledge
of what is happening at low levels?

> Cheers,
>    - Andreas
>

-- 
Best regards,
Igor Stasenko AKA sig.