9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Threading Model Questions
@ 2008-05-20 14:10 palazzol
  2008-05-20 18:50 ` erik quanstrom
  2008-05-21  0:37 ` Russ Cox
  0 siblings, 2 replies; 5+ messages in thread
From: palazzol @ 2008-05-20 14:10 UTC (permalink / raw)
  To: 9fans


Hello,

I've been looking into the Bell Labs CSP-style threading model, trying a few test programs, and watching the Russ Cox and Rob Pike movies.  I have a few of questions.

1) Are there any valid criticisms to this approach?  Everyone seems to agree it is superior to "lower-level" models, but are there any areas where this model doesn't work comparatively well?

2) Are there examples of the equivalence between this model and other ones (in terms of capability)

3) Why are the existing CSP-based libraries for other OS's (C++CSP2, JCSP, pyCSP) much more complex?  It seems like passing "channel ends" instead of channels might be a good idea, but the rest of the stuff seems like complexity with limited/no benefit?  For example, defining channels as One2One, One2Any, etc.  Also, the idea of scoped forking versus "free-form" thread/process creation.

4) Finally, it looks like libthread has support for a lot of non-CSP stuff.  Is this part used much?  Or is it just there for historical and/or completeness reasons.

Thanks for any opinions!
-Frank



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

* Re: [9fans] Threading Model Questions
  2008-05-20 14:10 [9fans] Threading Model Questions palazzol
@ 2008-05-20 18:50 ` erik quanstrom
  2008-05-21  0:37 ` Russ Cox
  1 sibling, 0 replies; 5+ messages in thread
From: erik quanstrom @ 2008-05-20 18:50 UTC (permalink / raw)
  To: 9fans

> 4) Finally, it looks like libthread has support for a lot of non-CSP stuff.  Is this part used much?  Or is it just there for historical and/or completeness reasons.

my simple search through thread.h yielded only these functions that i wouldn't
consider either part of thread/proc management, particular csp applications
(e.g. io* functions) or genuine csp:

	long	decref(Ref *r);			/* returns 0 iff value is now zero */
	void	incref(Ref *r);
	void	threadnonotes(void);
	int	threadnotify(int (*f)(void*, char*), int in);
	void	yield(void);

was there something else you had in mind?

- erik




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

* Re: [9fans] Threading Model Questions
  2008-05-20 14:10 [9fans] Threading Model Questions palazzol
  2008-05-20 18:50 ` erik quanstrom
@ 2008-05-21  0:37 ` Russ Cox
  2008-05-28  5:36   ` Frank Palazzolo
  1 sibling, 1 reply; 5+ messages in thread
From: Russ Cox @ 2008-05-21  0:37 UTC (permalink / raw)
  To: 9fans

> 1) Are there any valid criticisms to this approach?  Everyone seems to
> agree it is superior to "lower-level" models, but are there any areas
> where this model doesn't work comparatively well?

People often ask how you would structure an operating system
around communications primitives.  Certainly the higher-level
stuff can be done that way, but if you are multiplexing one cpu
between running user code, running OS code, and handling
driver interrupts, I don't see how to avoid locks.  It might be that
when we have 256-core processors, we'll just dedicate one core
to device interrupts and then use channels to talk to that core.

> 2) Are there examples of the equivalence between this model and other ones
> (in terms of capability)

I don't know what you mean by examples.  The classic paper
is Lauer and Needham, "On the Duality of Operating Systems Structures",
1978 (in Proc. Second International Symposium on Operating Systems)
and 1979 (in Operating Systems Review).

> 3) Why are the existing CSP-based libraries for other OS's (C++CSP2,
> JCSP, pyCSP) much more complex?  It seems like passing "channel ends"
> instead of channels might be a good idea, but the rest of the stuff
> seems like complexity with limited/no benefit?  For example, defining
> channels as One2One, One2Any, etc.  Also, the idea of scoped forking
> versus "free-form" thread/process creation.

Perhaps it is premature optimization, or perhaps it is just
complexity for complexity's sake.

> 4) Finally, it looks like libthread has support for a lot of non-CSP
> stuff.  Is this part used much?  Or is it just there for historical
> and/or completeness reasons.

Sometimes it is simply too tempting to resist a shared
data structure, and then you need qlocks or reference
counts or rsleep/rwakeup or some combination of the three.
This is more common in libraries that are trying simply to
be thread-safe without changing the interface to require
kicking off a central server process for whatever the shared
resource is.

For example, the generic protocol mux library in
Plan 9 from User Space is thread-safe and allows kicking
off procs to handle protocol reads and writes, but it
does not require them.  Thus it must use qlocks internally.
http://swtch.com/plan9port/man/man3/mux.html

Russ



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

* Re: [9fans] Threading Model Questions
  2008-05-21  0:37 ` Russ Cox
@ 2008-05-28  5:36   ` Frank Palazzolo
  0 siblings, 0 replies; 5+ messages in thread
From: Frank Palazzolo @ 2008-05-28  5:36 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs


I just wanted to say a belated thank you very much for your answers!

-Frank



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

* Re: [9fans] Threading Model Questions
@ 2008-05-20 21:21 palazzol
  0 siblings, 0 replies; 5+ messages in thread
From: palazzol @ 2008-05-20 21:21 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs, 9fans


Woops, sorry - I actually meant the stuff referenced in the lock(2) man page, which looks like it's not part of libthread.

-Frank

 -------------- Original message ----------------------
From: erik quanstrom <quanstro@quanstro.net>
> > 4) Finally, it looks like libthread has support for a lot of non-CSP stuff.
> Is this part used much?  Or is it just there for historical and/or completeness
> reasons.
>
> my simple search through thread.h yielded only these functions that i wouldn't
> consider either part of thread/proc management, particular csp applications
> (e.g. io* functions) or genuine csp:
>
> 	long	decref(Ref *r);			/* returns 0 iff value is now
> zero */
> 	void	incref(Ref *r);
> 	void	threadnonotes(void);
> 	int	threadnotify(int (*f)(void*, char*), int in);
> 	void	yield(void);
>
> was there something else you had in mind?
>
> - erik
>
>




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

end of thread, other threads:[~2008-05-28  5:36 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-05-20 14:10 [9fans] Threading Model Questions palazzol
2008-05-20 18:50 ` erik quanstrom
2008-05-21  0:37 ` Russ Cox
2008-05-28  5:36   ` Frank Palazzolo
2008-05-20 21:21 palazzol

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).