[squeak-dev] Another interesting behavior of Delay

I just found that its risky to use same instance of Delay, to wait by
more than single process.

| d sema t1 t2 first  |
 d := Delay forMilliseconds: 200.
sema := Semaphore new.
first := nil.
[ t1 := [ d wait. first ifNil: [ first := true]. ] timeToRun.  sema
signal ] forkAt: Processor activePriority +1.

[ (Delay forMilliseconds: 100) wait.
   t2 := [ d wait. first ifNil: [first := false]. ] timeToRun. sema
signal ] forkAt: Processor activePriority +1.

sema wait.
sema wait.

{ t1. t2. first.  }

both values, t1, t2 should be around 200 ms , because both processes
waiting for same delay, right?
But code always returns #(300 200 true)

Of course, delay not guarantees that time elapsed will be the same as
requested, because some higher priority process
could simply prevent from activating the process with elapsed delay.
But in given code, there is no such process.

The 'first' flag is true, which means that process, who created first,
gaining control after waiting on delay before second process,
which makes things even more odd, because scheduling the same delay
for a second time should not change the awake time of first one.

The main reason , why i would want to reuse same delay instance, is to
conserve space and not produce the garbage
by creating a new Delay instance each time i want to put delay:

"at some initialization "
MyDelayClassVar := Delay forMilliseconds: 100.


and then somewhere in another method:

someMethod
   x to: y do: [ self doSomeThing. MyDelayClassVar  wait. ]

and as i illustrated, if #someMethod used by multiple processes, it
starts behaving interestingly :)

--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko wrote:
> I just found that its risky to use same instance of Delay, to wait by
> more than single process.

Eeek! That's a bug. The recent cleanup for removing some of the older
delay stuff accidentally removed the (very necessary!) test.

Test and fix will be coming in 3 .. 2 .. 1 ..

Cheers,
   - Andreas

Another illustration that there is something wrong with scheduling the
same delay multiple times:

| d sema t1 t2 t3   |
 d := Delay forMilliseconds: 200.
sema := Semaphore new.
first := nil.
[ d wait. t1:= Time millisecondClockValue. sema signal ] forkAt:
Processor activePriority +1.
[ (Delay forMilliseconds: 100) wait.
   d wait. t2 := Time millisecondClockValue. sema signal ] forkAt:
Processor activePriority -1.
[ (Delay forMilliseconds: 150) wait.
   d wait. t3 := Time millisecondClockValue. sema signal ] forkAt:
Processor activePriority -1.
sema wait.
sema wait.
sema wait.

{ t1. t2. t3 } - Time millisecondClockValue

prints #(0 0 0)
while obviously, different processes should have different time of
returning from wait.

I'm also increased the delays by 10x factor (i.e. 2000, 1000, 1500),
and still having #(0 0 0) as result.

--
Best regards,
Igor Stasenko AKA sig.

2009/9/22 Andreas Raab <[hidden email]>:
I seen your commits.
So, as i understand, your changes makes sure that delay can be
scheduled only once at some point of time.
This surely makes things more predictable, but limits the use cases :(

> Cheers,
>  - Andreas
>

--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko wrote:
> I seen your commits.
> So, as i understand, your changes makes sure that delay can be
> scheduled only once at some point of time.

Yes, that is the way it has always been.

> This surely makes things more predictable, but limits the use cases :(

Well, it's easy enough to create another delay isn't it? I can't really
see a use-case that would *require* sharing the same delay across
multiple processes.

Cheers,
   - Andreas

2009/9/22 Andreas Raab <[hidden email]>:
Its ok as to me.
I'm just making a difference between things which just working, and
things which working perfectly,
without any doubts :)


> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.