Re: [9fans] GSOC proposal for plan9

[erik quanstrom]

 [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

[9fans] GSOC proposal for plan9

[yan cui]

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.