[Vm-dev] why does #resume affect waiting semaphore

[tim Rowledge]

> On 19-02-2016, at 4:40 AM, Ben Coman <btc at openinworld.com> wrote:
> 
> 
> Just a curiosity I've had for a while.  Intuituvely I would expect the
> following produce { } since sem is never signalled.
> 
>   log := OrderedCollection new.
>   sem := Semaphore new.
>   p1 := [sem wait. log add: 1] forkAt: 41.
>   p2 := [sem wait. log add: 2] forkAt: 41.
>   p2 resume.
>   log inspect.
> 
> but it produces {2}.

I never find it easy to think about Semaphores but basically waiting on one suspends the Process, then signalling it does the equivalent of
excessSigs := excessSigs +1.
excessSigs > 0 ifTrue: [mySuspendedProcess resume]

So manually sending resume to the process bypasses the wait.

Things to try to see if any of it makes sense (which honestly, it doesn’t. It’s like quantum electrodynamics or Spinor Calculus - nobody that understands it actually understands it)

  log := OrderedCollection new.
  sem := Semaphore new.
  p1 := [sem wait. log add: 1] forkAt: 41.
  p2 := [sem wait. sem wait. log add: 2] forkAt: 41.
  p2 resume.
  log inspect.
This one has a second wait in p2 and so the resume just gets you to that second wait.

  log := OrderedCollection new.
  sem := Semaphore new.
  p1 := [sem wait. log add: 1] forkAt: 41.
  p2 := [sem wait. log add: 2] forkAt: 41.
  sem signal.
  p2 resume.
  log inspect.

  log := OrderedCollection new.
  sem := Semaphore new.
  p1 := [sem wait. log add: 1] forkAt: 41.
  p2 := [sem wait.  log add: 2] forkAt: 41.
  p2 resume.
  sem signal.
  log inspect.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
May the bugs of many programs nest on your hard drive.