#fork and deterministic resumption of the resulting process

Igor Stasenko siguctua at gmail.com
Fri Feb 8 08:40:06 UTC 2008


On 08/02/2008, Andreas Raab <andreas.raab at gmx.de> wrote:
> Igor Stasenko wrote:
> > I'd like to emphasize this (please, increase the font size, when you
> > reading following phrase):
> >
> > ...  a program that relies on a particular implementation of
> > scheduling is wrong.
>
> Sorry but that's complete nonsense. If you really believe this then I'll
> challenge you to write a program that you believe is "correct" for the
> following problem: Create a program that will write the numbers 1
> through five from five concurrent threads into an array in the order 1,
> 2, 3, 4, 5. Something that today you could do for example via:
>
> result := Array new: 5.
> 1 to: 5 do:[:i|
>    [result at: i put: i] forkAt: Processor activePriority+1.
> ].
>
I'll write only a block code, if you don't mind:

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

> *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?
This is apparently the case, when you using wrong tool to solve the problem.
So, it's not really matter if my code will work, or will not, it's simply wrong.


> Cheers,
>    - Andreas
>
>


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list