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).

>> *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.

Cheers,
   - Andreas