From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
Date: Sat, 15 Mar 2014 20:17:22 -0400
Message-ID: <CAAVq3rkSXYx0dDAL52bupYhUbxjfM_yEtcGb9kr8foigOyTfmA@mail.gmail.com>
From: yan cui <ccuiyyan@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: multipart/alternative; boundary=20cf303b400515ed8d04f4ae3aea
Subject: [9fans] GSOC proposal for plan9
Topicbox-Message-UUID: cad39c16-ead8-11e9-9d60-3106f5b1d025

--20cf303b400515ed8d04f4ae3aea
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

   I have noticed the comments of  Anthony Sorace and Quanstro in my GSOC
proposal. Thanks very much! Basically, there are three problems.
[1]. The timeline has the time of reading related documents and source
codes, but Anthony thinks it should be solved before the coding stage.
[Yan] I have removed the reading stage from the timeline and use the time
to write code and do some testing.

[2]. I did not add the considerations of testing and measurements.
[Yan] in the updated proposal, I add my idea of testing in the timeline
part.
Basically, I plan to write some code to stress the MCS lock in different
contention degree and see whether the MCS lock works as expected.
In addition, I plan to run some macro-benchmarks to test the performance of
MCS lock, and compared with the original TAS (test and set) implementation.
Quanstro, is that enough?

[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)?

Please provide comments, and I will update my proposal accordingly.
Best Wishes!
Yan

--
Think big; Dream impossible; Make it happen.

--20cf303b400515ed8d04f4ae3aea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div><div>Dea=
r all,<br><br></div>=A0=A0 I have noticed the comments of=A0 Anthony Sorace=
 and Quanstro in my GSOC proposal. Thanks very much! Basically, there are t=
hree problems.<br>
</div>[1]. The timeline has the time of reading related documents and sourc=
e codes, but Anthony thinks it should be solved before the coding stage. <b=
r></div>[Yan] I have removed the reading stage from the timeline and use th=
e time to write code and do some testing. <br>
<br></div>[2]. I did not add the considerations of testing and measurements=
. <br></div>[Yan] in the updated proposal, I add my idea of testing in the =
timeline part.<br></div>Basically, I plan to write some code to stress the =
MCS lock in different contention degree and see whether the MCS lock works =
as expected. <br>
</div>In addition, I plan to run some macro-benchmarks to test the performa=
nce of MCS lock, and compared with the original TAS (test and set) implemen=
tation. Quanstro, is that enough? <br><br></div>[3]. Should avoid the paten=
t issue of the K42 system.<br>
</div>[Yan] For this problem, I do not have any idea right now. Do we need =
to propose a different solution (from K42&#39;s MCS lock), but solve the sa=
me problem (do not need to pass node data structure in the parameter)?<br>
<br></div><div>Please provide comments, and I will update my proposal accor=
dingly.<br></div>Best Wishes!<br></div>Yan=A0 <br><div><div><div><div><div>=
<div><div><div><div><div><div><div><strong></strong><div><div><br>-- <br>
<div>Think big; Dream impossible; Make it happen.=A0=A0</div>
</div></div></div></div></div></div></div></div></div></div></div></div></d=
iv></div></div>

--20cf303b400515ed8d04f4ae3aea--