From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Sun, 16 Mar 2014 10:38:15 -0400
To: ccuiyyan@gmail.com, 9fans@9fans.net
Message-ID: <c4f507c05e09757fa00f035d59600075@brasstown.quanstro.net>
In-Reply-To: <CAAVq3rkSXYx0dDAL52bupYhUbxjfM_yEtcGb9kr8foigOyTfmA@mail.gmail.com>
References: <CAAVq3rkSXYx0dDAL52bupYhUbxjfM_yEtcGb9kr8foigOyTfmA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] GSOC proposal for plan9
Topicbox-Message-UUID: caed2316-ead8-11e9-9d60-3106f5b1d025

> [3]. Should avoid the patent issue of the K42 system.
> [Yan] For this problem, I do not have any idea right now. Do we need to
> propose a different solution (from K42's MCS lock), but solve the same
> problem (do not need to pass node data structure in the parameter)?

of course the simplist version of this is allocating Qnodes internally.
this can be done locklessly because held locks cannot switch Mach.
alternatively, since we *can* modify the definition of the the structure
Lock, MAXMACH Qnodes could be part of the lock.

i'm sure that you'll have good ideas on this, too.

- erik