[9fans] double lock in proc.c

[9fans] double lock in proc.c

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

In /sys/src/9/port/proc.c a comment state:

/*
* Expects that only one process can call wakeup for any given Rendez.
* We hold both locks to ensure that r->p and p->r remain consistent.
* Richard Miller has a better solution that doesn't require both to
* be held simultaneously, but I'm a paranoid - presotto.
*/

(see
https://github.com/0intro/plan9/blob/master/sys/src/9/port/proc.c#L882-L887)

I'd like to know a bit more about Miller's solution as I'd like to simplify
postnote.
Any hint or source code?


Giacomo

[-- Attachment #2: Type: text/html, Size: 750 bytes --]

Re: [9fans] double lock in proc.c

[Erik Quanstrom]

[-- Attachment #1: Type: text/html, Size: 1356 bytes --]

Re: [9fans] double lock in proc.c

[Fran. J Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

do you remember the proposal?
thanks

> El 24 jul 2017, a las 18:39, Erik Quanstrom <quanstro@quanstro.net> escribió:
> 
> I had a discussion with Richard about this a few years ago.  Richard was no longer convinced of the solution.  at the time I agreed with his reasoning.  the comment should be changed.
> 
> - erik
> 
> 
> On Jul 24, 2017 9:03 AM, Giacomo Tesio <giacomo@tesio.it> wrote:
> In /sys/src/9/port/proc.c a comment state:
> 
> /*
> * Expects that only one process can call wakeup for any given Rendez.
> * We hold both locks to ensure that r->p and p->r remain consistent.
> * Richard Miller has a better solution that doesn't require both to
> * be held simultaneously, but I'm a paranoid - presotto.
> */
> 
> (see https://github.com/0intro/plan9/blob/master/sys/src/9/port/proc.c#L882-L887)
> 
> I'd like to know a bit more about Miller's solution as I'd like to simplify postnote.
> Any hint or source code?
> 
> 
> Giacomo
> 

[-- Attachment #2: Type: text/html, Size: 1725 bytes --]

Re: [9fans] double lock in proc.c

[Richard Miller]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

I'm not convinced that I recall not being convinced ... :)

Essentially I changed the order of lock acquire/release so that the
canlock() loop in proc.c:/^postnote could be eliminated.  Not significant
for performance, but it seemed more elegant and I think it also avoided
looking at any shared data outside code regions protected by a lock.

This was many years ago (when my now-white beard was still merely grey).
Not worth going back to reconstruct the arguments, but I'll send Giacomo
and Nemo a copy of my proc.c to examine for themselves.

On 24 July 2017 at 20:13, Fran. J Ballesteros <nemo@lsub.org> wrote:

> do you remember the proposal?
> thanks
>
> El 24 jul 2017, a las 18:39, Erik Quanstrom <quanstro@quanstro.net>
> escribió:
>
> I had a discussion with Richard about this a few years ago.  Richard was
> no longer convinced of the solution.  at the time I agreed with his
> reasoning.  the comment should be changed.
>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 1576 bytes --]

Re: [9fans] double lock in proc.c

[David du Colombier]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

This was many years ago (when my now-white beard was still merely grey).
Not worth going back to reconstruct the arguments, but I'll send Giacomo
and Nemo a copy of my proc.c to examine for themselves.


I'd also be interested by your copy if proc.c.

Thanks.

--
David du Colombier

[-- Attachment #2: Type: text/html, Size: 754 bytes --]