code review 4974043: runtime: improve locking on openbsd

runtime: improve locking on openbsd

Implement a locking model based on the current linux model - a
tri-state mutex with active spinning, passive spinning and sleeping.

[jsing, 2011-10-07 14:09:25]

Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[dvyukov, 2011-10-07 14:18:57]

I think it's a dead end to try to optimize all those implementations separately.
I have a patch that unifies all mutex implementations to just 2 (futex and
semaphore based):
http://codereview.appspot.com/5140043/
I think it's better to complete that patch.

[dvyukov, 2011-10-07 14:38:10]

On 2011/10/07 14:18:57, dvyukov wrote:
> I think it's a dead end to try to optimize all those implementations
separately.
> I have a patch that unifies all mutex implementations to just 2 (futex and
> semaphore based):
> http://codereview.appspot.com/5140043/
> I think it's better to complete that patch.

I think I will measure performance difference between futex and semaphore on
linux. If it is not that much then we may end up with just 1 mutex
implementation.

[jsing, 2011-10-07 14:51:02]

On 2011/10/07 14:18:57, dvyukov wrote:
> I think it's a dead end to try to optimize all those implementations
separately.
> I have a patch that unifies all mutex implementations to just 2 (futex and
> semaphore based):
> http://codereview.appspot.com/5140043/
> I think it's better to complete that patch.

I like the idea of moving to a consistent/shared locking model, rather than
having one per operating system, however I'm not sure that it should block this
change.

I believe that this change will address the time/scheduling issues that are
being seen on the openbsd amd64 buildbot. Also, AFAIK OpenBSD does not have
lightweight semaphores (unless you link against libpthread) or an exact futex
equivalent, so you'll likely need some of the code/behaviour that is in this
change anyway.

[rsc, 2011-10-07 15:02:19]

I agree that it's fine to move forward with this even if
Dmitriy is going to unify the mutex implementations later.

Where can I find the semantics of thrsleep and thrwakeup?
The C prototypes in this CL do not match the comments at
http://fxr.watson.org/fxr/source/sys/syscall.h?v=OPENBSD
and I have been unable to find out what the arguments mean.

Russ

[jsing, 2011-10-07 15:15:12]

On 2011/10/07 15:02:19, rsc wrote:
> I agree that it's fine to move forward with this even if
> Dmitriy is going to unify the mutex implementations later.
> 
> Where can I find the semantics of thrsleep and thrwakeup?
> The C prototypes in this CL do not match the comments at
> http://fxr.watson.org/fxr/source/sys/syscall.h?v=OPENBSD
> and I have been unable to find out what the arguments mean.

That syscall.h is a bit old... have a look at:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/syscall.h?rev=1.130;content...

Or the kernel implementation:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_synch.c?rev=1.97;cont...

Example usage is also provided in librthreads:

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/librthread/rthread_sync.c?rev=1...

[rsc, 2011-10-07 15:25:59]

LGTM

[jsing, 2011-10-08 13:56:21]

*** Submitted as http://code.google.com/p/go/source/detail?r=3894889d5c1c ***

runtime: improve locking on openbsd

Implement a locking model based on the current linux model - a
tri-state mutex with active spinning, passive spinning and sleeping.

R=golang-dev, dvyukov, rsc
CC=golang-dev
http://codereview.appspot.com/4974043

[dvyukov, 2011-10-10 12:54:47]

On 2011/10/07 14:51:02, jsing wrote:
> On 2011/10/07 14:18:57, dvyukov wrote:
> > I think it's a dead end to try to optimize all those implementations
> separately.
> > I have a patch that unifies all mutex implementations to just 2 (futex and
> > semaphore based):
> > http://codereview.appspot.com/5140043/
> > I think it's better to complete that patch.
> 
> I like the idea of moving to a consistent/shared locking model, rather than
> having one per operating system, however I'm not sure that it should block
this
> change.
> 
> I believe that this change will address the time/scheduling issues that are
> being seen on the openbsd amd64 buildbot. Also, AFAIK OpenBSD does not have
> lightweight semaphores (unless you link against libpthread) or an exact futex
> equivalent, so you'll likely need some of the code/behaviour that is in this
> change anyway.

Agree