9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] GSOC proposal for plan9
@ 2014-03-16  0:17 yan cui
  2014-03-16 14:38 ` erik quanstrom
  0 siblings, 1 reply; 2+ messages in thread
From: yan cui @ 2014-03-16  0:17 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

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.

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [9fans] GSOC proposal for plan9
  2014-03-16  0:17 [9fans] GSOC proposal for plan9 yan cui
@ 2014-03-16 14:38 ` erik quanstrom
  0 siblings, 0 replies; 2+ messages in thread
From: erik quanstrom @ 2014-03-16 14:38 UTC (permalink / raw)
  To: ccuiyyan, 9fans

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



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-03-16 14:38 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-16  0:17 [9fans] GSOC proposal for plan9 yan cui
2014-03-16 14:38 ` erik quanstrom

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).