On 08/02/2008, Andreas Raab <andreas.raab at gmx.de> wrote:
> Igor Stasenko wrote:
> > I'll write only a block code, if you don't mind:
>
> Sure.
>
> > [ i == 1 ifTrue:[ result at: i put: i] ifFalse: [ [ (result at: i-1)
> > isNil ] whileTrue: [].
> > result at: i put: i ] ]
> >
> > .. this will work with assumption that each block keeps own, separate
> > copy of i in it's own context. Otherwise there is need to add code to
> > ensure this.
>
> This doesn't even come close. You can easily see this simply by assuming
> that a theoretical scheduler schedules later threads with a slightly
> higher priority and runs them like todays scheduler. So it would be
> roughly equivalent to the following:
>
> 1 to: 5 do:[:i|
>    [ i == 1 ifTrue:[ result at: i put: i] ifFalse: [ [ (result at: i-1)
> isNil ] whileTrue: [].
>    result at: i put: i ] ] forkAt: Processor activePriority - 10 + i.
> ].
>
> This simply won't do. Try again please. (BTW, for clarification, I
> expect that when the "program" completes that the result array is filled
> in).
>
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.
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>

> >> *Regardless* of your implementation I will define a scheduling mechanism
> >> that breaks your program, e.g., make it behave "wrong". In other words
> >> if you believe what you write above you won't *ever* be able to write
> >> correct multi-threaded code.
> >
> > Unless you define a scheduling mechanism, which performs program
> > actions in random order (not in sequence, which developer defined).
> >
> > Now answer me, please, is such kind of tasks (where you need to
> > perform action only after previous is complete) worth using concurrent
> > threads of execution?
>
> It's not. But that's not my point. You claimed you can write "correct"
> code without assuming anything about scheduling. I'm simply disproving
> you. I'm willing to use any other non-trivial example you can come up
> with (with "trivial" being defined as non-interacting processes). I am
> only using the simplest set of interacting processes I could possibly
> think of - a sequence.
>
The only assumption about scheduling, that it allows processes to run
in parallel.
E.g., if you have N processes and K seconds of time, there is some K,
when each process will have a chance to perform at least single
action.

> Cheers,
>    - Andreas
>
>


-- 
Best regards,
Igor Stasenko AKA sig.