[Pharo-users] Semaphore wait and signal

phil at highoctane.be phil at highoctane.be
Tue May 10 11:03:44 EDT 2016


Transcript output logic is wicked, flush or not. Especially if you Halt now.

Check for stepGlobal senders and implmenters and see it in all its glory
with flags and all.

You can then understand why things are weird.

Some World doOneCycle peppered around may confuse things a bit more.

Use a log file and tail -f it if you are on OSX or Linux.

It will at least be in the order you issue things.

Phil


On Tue, May 10, 2016 at 1:15 PM, Johan Fabry <jfabry at dcc.uchile.cl> wrote:

> Hi Vince,
>
> some of your problem may be in the Transcript buffering some of its
> output. It is best to add a ; flush to the end of all your printing, e.g.
> Transcript show: 'waiting...'; cr ; flush.
>
> HTH
>
> On May 10, 2016, at 07:31, Vince Refiti <vinref at gmail.com> wrote:
>
> Hello
>
> I am playing around with Semaphore, and wrote the following:
>
> | coll count sem |
> coll := Array withAll: (1 to: 100).
> count := 0.
> sem := Semaphore new.
> coll do: [ :each |
>     count := count + 1.
>     (count >= 5)
>         ifTrue: [
>             Transcript show: 'waiting...'; cr.
>             sem wait ].
>
>     [ [ 2 seconds asDelay wait.
>          Transcript show: each printString, ' ', count printString; cr ]
> ensure: [
>             count := count -1.
>             sem signal ] ] fork ]
>
> The output is:
>
> waiting...
> 1  End of statement list encountered ->5
> 2 4
> 3 3
> 4 2
> waiting...
> waiting...
> waiting...
> waiting...
> 5 8
> 6 7
> 7 6
> 8 5
> 9 4
> 10 3
> 11 2
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> 12 11
> 13 10
> 14 9
> 15 8
> 16 7
> 17 6
> 18 5
> 19 4
> 20 3
> 21 2
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> 22 14
> 23 13
> 24 12
> 25 11
> 26 10
> 27 9
> 28 8
> 29 7
> 30 6
> 31 5
> 32 4
> 33 3
> 34 2
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> 35 17
> 36 16
> 37 15
> 38 14
> 39 13
> 40 12
> 41 11
> 42 10
> 43 9
> 44 8
> 45 7
> 46 6
> 47 5
> 48 4
> 49 3
> 50 2
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> 51 20
> 52 19
> 53 18
> 54 17
> 55 16
> 56 15
> 57 14
> 58 13
> 59 12
> 60 11
> 61 10
> 62 9
> 63 8
> 64 7
> 65 6
> 66 5
> 67 4
> 68 3
> 69 2
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> 70 23
> waiting...
> 71 23
> 72 22
> 73 21
> 74 20
> 75 19
> 76 18
> 77 17
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> waiting...
> 78 23
> 79 22
> 80 21
> 81 20
> 82 19
> 83 18
> 84 17
> 85 16
> 86 15
> 87 14
> 88 13
> 89 12
> 90 11
> 91 10
> 92 9
> 93 8
> 94 7
> 95 6
> 96 5
> 97 4
> 98 3
> 99 2
> 100 1
>
> I was expecting 'waiting...' to alternate with the 'each-count' lines.
> Also the entire statement paused for 2 seconds, spat out some lines, then
> waited a little longer, and then finished.
>
> Can someone please explain this pattern?
>
> Thanks, Vince
>
>
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University
> of Chile
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160510/0174a4a1/attachment.html>


More information about the Pharo-users mailing list