[Ann] ReadWriteLock

How does your ReadWriteLock compare to Monitor? I was under the impression that what you describe could be done with a Monitor.

Quite elegant! :)

Is this meant to be part of the main distribution?

Doru


--
www.tudorgirba.com
www.feenk.com

"What is more important: To be happy, or to make happy?"

Hi,

If I understand correctly:
- the Monitor only offer one kind of critical section that typically affects everyone equally,
- while with the new ReadWriteLock, the readers will be blocked only if a writer will acquire the writer critical section.

Cheers,
Doru


--
www.tudorgirba.com
www.feenk.com

“Live like you mean it."

On Tue, Jan 5, 2016 at 1:39 AM, Denis Kudriashov <[hidden email]> wrote:


I don't think /writeIsLocked/ is a good variable name in
#criticalWrite: .   Even though its a local var, its semantic "feels"
object wide.  Consider process A enters #criticalWrite and gains the
write lock, then process B enters #criticalWrite: where it does
"writeIsLocked := false" -- but A still has the lock, so the semantic
is confusing.  Perhaps renaming to something like "ensureRelease" is
more intention revealing.

waiting inside the ensure-main-block is interrupted.  If B is
terminated, then the ensure-block executes

Now there is a problem with the logic of #criticalWrite:
Consider a scenario where process p1 is holding the writersSemaphore
for a long time, and processes p2 and p3 are waiting on it.  If p2 is
terminated, then its ensure-block executes, which signals
writersSemaphore  and p3 proceeds prematurely.  By way of example, try
this...

  | lock p1 p2 p3|
  Transcript clear.
  lock := ReadWriteLock new.
  p1 := [ Transcript crShow: '1A'. lock criticalWrite: [ Transcript
crShow: '1B'.  self halt ] ]
                newProcess name: 'LOCK1' .
  p2 := [ Transcript crShow: '2A'. lock criticalWrite: [ Transcript
crShow: '2B' ] ]
                newProcess name: 'LOCK2' .
  p3 := [ Transcript crShow: '3A'. lock criticalWrite: [ Transcript
crShow: '3B' ] ]
                newProcess name: 'LOCK3' .
  p1 resume.
  p2 resume.
  p3 resume.
" (1 second wait).
  p2 terminate.
"

...with the last two lines commented, you get the expected result...
A1
A2
B1
C1
"Correctly pauses until <Proceed> debugger"
B2
C2

..but if you uncomment the last two lines you get...
1A
1B
2A
3A
"whoops, did not pause here until <Proceed> in debugger"
3B

You can observe this further by adding the following logging to the
top of the ensure block...
  ] ensure: [
  Transcript crShow: writersSemaphore excessSignals ; tab ; show:
activeProcess == writeLockOwner ; tab ; show: aBlock.
  ...


So when p2 is terminated, it is no longer waiting on
/writersSemaphore/ and thus will not be consuming a signal, so we
should avoid signalling it when the process it terminated.

One solution might be...
  criticalWrite: aBlock
    | activeProcess ensureRelease blockResult|
    activeProcess := Processor activeProcess.
    activeProcess == writeLockOwner ifTrue:[ ^aBlock value].
    ensureRelease := false.
    blockResult := [
        ensureRelease := true.
        writersSemaphore wait.
        writeLockOwner := activeProcess.
        aBlock value
        ] ensure: [
            "Need to avoid signalling when terminated, since it never
consumed a signal"
            (ensureRelease and:
                [ activeProcess == writeLockOwner ])  ifTrue: [
            writeLockOwner := nil.
            writersSemaphore signal ].
            ].
   ^ blockResult



Now I was curious why Semaphore>>critical: did not exhibit the same
problem, since the following...
  | lock p1 p2 p3|
  Transcript clear.
  lock := Semaphore forMutualExclusion.
  p1 := [ Transcript crShow: '1A'. lock critical: [ Transcript crShow:
'1B'.  self halt ] ]
                newProcess name: 'LOCK1' .
  p2 := [ Transcript crShow: '2A'. lock critical: [ Transcript crShow: '2B' ] ]
                newProcess name: 'LOCK2' .
  p3 := [ Transcript crShow: '3A'. lock critical: [ Transcript crShow: '3B' ] ]
                newProcess name: 'LOCK3' .
  p1 resume.
  p2 resume.
  p3 resume.
  (1 second wait).
  p2 terminate.

which produces...
1A
1B
2A
3A
"Correctly pauses until <Proceed> debugger"
3B


However, if I copy Semaphore to Semaphore2 and do this...
  | lock p1 p2 p3|
  Transcript clear.
  lock := Semaphore2 forMutualExclusion.
  p1 := [ Transcript crShow: '1A'. lock critical: [ Transcript crShow:
'1B'.  self halt ] ]
                newProcess name: 'LOCK1' .
  p2 := [ Transcript crShow: '2A'. lock critical: [ Transcript crShow: '2B' ] ]
                newProcess name: 'LOCK2' .
  p3 := [ Transcript crShow: '3A'. lock critical: [ Transcript crShow: '3B' ] ]
                newProcess name: 'LOCK3' .
  p1 resume.
  p2 resume.
  p3 resume.
  (1 second wait).
  p2 terminate.

it produces...
1A
1B
2A
3A
"whoops, did not pause here until <Proceed> in debugger"
3B

This is really strange!  Why does the copied class Semaphore2 behave
differently to the original class Semaphore? This was in build 50510.


btw I have this growing suspicion that we should eliminate
Semaphore>>critical: and Semaphore>>forMutualExclusion.   Semaphores
on their own should *not* provide a facility for to protect critical
regions since they suffer from accidental release [1] due to
*lack*of*ownership*.   This is the root cause of the problem scenario
above.  Mutex>>critical: which does have a sense of ownership should
be used instead.  Indeed, [2] advises "The correct use of a semaphore
is for *signaling* from one task to another. A mutex is meant to be
taken and released, always in that order, by *[the same]* task that
uses the shared resource it protects." -- But this is a subtle
distinction and having Semaphore>>critical: leads people to incorrect
thinking and exposes them to subtle errors.

Mutex>>critical: cold still be implemented using Semaphore, but rather
than just forwarding to Semaphore>>critical: pull that method's code
out into Mutex>>critical: so it looks like what  Denis did for
#criticalWrite:    Or alternatives, we should consider directly using
the mutex primitives Eliot mentioned some time ago were already in the
VM.

[1] https://blog.feabhas.com/2009/09/mutex-vs-semaphores-%E2%80%93-part-1-semaphores/
[2] http://www.barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore

cheers -ben

On Tue, Jan 5, 2016 at 11:59 PM, Denis Kudriashov <[hidden email]> wrote:
But Semaphore>>forMutualExclusion *encourages* people to believe
semaphores can be used *on*their*own* for mutual exclusion, when they
*shouldn't*.  You *must* add ownership.  If the mutual exclusion
object doesn’t have ownership then, irrelevant of what it is called,
it is not a mutex!!! [1].

"Strictly speaking [2]...
  -- A mutex is *locking* mechanism used to synchronize access to a
resource. Only one task (can be a thread or process based on OS
abstraction) can acquire the mutex. It means there is *ownership*
associated with mutex, and only the owner can release the lock
(mutex).
  -- A semaphore is *signaling* mechanism (“I am done, you can carry
on” kind of signal). For example, if you are listening songs (assume
it as one task) on your mobile and at the same time your friend calls
you, an interrupt is triggered upon which an interrupt service routine
(ISR) signals the call processing task to wakeup


>It is common case that semaphore "free" by default.

With an implementation like..
    Semaphore>>forMutualExclusion
        ^self new signal

we don't gain a lot, and its a misleading convenience method since its
doesn't provide the proper facility for mutual exclusion (and I do
conflate mutual exclusion == mutex).   Indeed, "Semaphore
forMutualExclusion + roll your ownership management + problems since
you weren't aware you needed to roll your own ownership management" is
not more convenient than "Mutex new"

If you want to keep a convenience method for a pre signalled
Semaphore, then we could provide something like  "Semaphore
newSignalled"

> And this name is explicitly said about this.

Actually no.  It explicitly says it provides mutual exclusion - which
without ownership, it does not. It only implicitly provides a
pre-signalled Semaphore - you have to *know* of look at the source.

[1]  https://blog.feabhas.com/2009/09/mutex-vs-semaphores-%E2%80%93-part-2-the-mutex/
[2] http://www.geeksforgeeks.org/mutex-vs-semaphore/

cheers -ben

On Wed, Jan 6, 2016 at 12:30 AM, Henrik Johansen
<[hidden email]> wrote:
After Semaphore to Semaphore2 and running my test case above showing
its bad terminate behaviour without the special handling in
Process>>terminate,  I then copied Mutex to Mutex2 and made the
following mod...
  Mutex2>>initiialize
    super initialize.
    semaphore := Semaphore2 forMutualExclusion.

such that my test case with
    lock := Mutex2 new.
also showed the bad terminate behaviour.

But then copying Mutex2 to Mutex3 with the following mod to replace
the call to Semaphore>>critical:...

  Mutex3>>critical: aBlock
    "Evaluate aBlock protected by the receiver."
    | activeProcess ensureRelease blockResult|
    activeProcess := Processor activeProcess.
    activeProcess == owner ifTrue:[^aBlock value].
    ensureRelease := false.
    blockResult := [
      ensureRelease := true.
      semaphore wait.
      owner := activeProcess.
      aBlock value
      ] ensure: [
        (ensureRelease and: [ activeProcess == owner ]) ifTrue: [
          owner := nil.
          semaphore signal ]
        ].
  ^blockResult

and my test case with
      lock := Mutex3 new.
works fine .

So again I push that Semaphore>critical: is *bad*.

>
> So somebody definitely know about #critical: selector and it receiver

#critical: is mutual exclusion, thus a Mutex, not a Semaphore.

>
>
> Yes, check Process >> #terminate, there's special code for skipping a
> context if the suspended process was waiting for Semaphore.

Well spotted.

Simply, if we eliminate Semaphore>>critical: then of course no special
processing is required in Process>>terminate.  I suggest that after a
bit of review and testing, all we'll need is  Mutex3>>critical:
described above.

cheers -ben