Ruby Fibers (was: threads?)
On Tue, Oct 12, 2010 at 07:22:33AM -0700, Damian Conway wrote: > > What we really need is some anecdotal evidence from folks who are actually > using threading in real-world situations (in *any* languages). What has worked > in practice? What has worked well? What was painful? What was error-prone? > And for which kinds of tasks? > > And we also need to stand back a little further and ask: is "threading" > the right approach at all? Do threads work in *any* language? Are there > better metaphors? I've not used them, but Ruby 1.9 Fibers (continuations) and the EventMachine Reactor pattern seem interesting. http://www.igvita.com/2009/05/13/fibers-cooperative-scheduling-in-ruby/ http://www.igvita.com/2010/03/22/untangling-evented-code-with-ruby-fibers/ There's also an *excellent* screencast by Ilya Grigorik. It's from a Ruby/Rails perspective but he gives a good explanation of the issues. He shows how writing async code using callbacks rapidly gets complex and how continuations can be used to avoid that. Well worth a look: http://blog.envylabs.com/2010/07/no-callbacks-no-threads-ruby-1-9/ Tim. p.s. If short on time start at 15:00 and watch to at least 28:00.
Lessons to learn from ithreads (was: threads?)
On Tue, Oct 12, 2010 at 03:42:00PM +0200, Leon Timmermans wrote: > On Mon, Oct 11, 2010 at 12:32 AM, Ben Goldberg > wrote: > > If thread-unsafe subroutines are called, then something like ithreads > > might be used. > > For the love of $DEITY, let's please not repeat ithreads! It's worth remembering that ithreads are far superior to the older 5005threads model, where multiple threads ran with an interpreter. [Shudder] It's also worth remembering that real O/S level threads are needed to work asynchronously with third-party libraries that would block. Database client libraries that don't offer async support are an obvious example. I definitely agree that threads should not be the dominant form of concurrency, and I'm certainly no fan of working with O/S threads. They do, however, have an important role and can't be ignored. So I'd like to use this sub-thread to try to identify when lessons we can learn from ithreads. My initial thoughts are: - Don't clone a live interpreter. Start a new thread with a fresh interpreter. - Don't try to share mutable data or data structures. Use message passing and serialization. Tim.
Re: threads?
I haven't enough smarts to see if this is at all what you're looking for but is used some of the same terms: http://dpj.cs.uiuc.edu/DPJ/Home.html?cid=nl_ddjupdate_2010-10-12_html Welcome to the home page for the Deterministic Parallel Java (DPJ) project at the University of Illinois at Urbana-Champaign. Project Overview The broad goal of our project is to provide deterministic-by-default semantics for an object-oriented, imperative parallel language, using primarily compile-time checking. ?Deterministic? means that the program produces the same visible output for a given input, in all executions. ?By default? means that deterministic behavior is guaranteed unless the programmer explicitly requests nondeterminism. This is in contrast to today?s shared-memory programming models (e.g., threads and locks), which are inherently nondeterministic and can even have undetected data races. Our paper at HotPar 2009 states our research goals in more detail. The other pages of this site provide additional information about the DPJ type system and language. a -- Andy Bach Systems Mangler Internet: andy_b...@wiwb.uscourts.gov Voice: (608) 261-5738; Cell: (608) 658-1890 No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962)
Re: threads?
On Tue, Oct 12, 2010 at 10:43:44PM +0200, Leon Timmermans wrote: > On Tue, Oct 12, 2010 at 4:22 PM, Damian Conway wrote: > > The problem is: while most people can agree on what have proved to be > > unsatisfactory threading models, not many people can seem to agree on > > what would constititute a satisfactory threading model (or, possibly, > > models). > > > > What we really need is some anecdotal evidence from folks who are actually > > using threading in real-world situations (in *any* languages). What has > > worked > > in practice? What has worked well? What was painful? What was error-prone? > > And for which kinds of tasks? > > Most languages either implement concurrency in a way that's not very > useful (CPython, CRuby) or implement it in a way that's slightly > (Java/C/C++) to totally (perl 5) insane. Erlang is the only language > I've worked with whose threads I really like, but sadly it's rather > weak at a lot of other things. > > In general, I don't feel that a shared memory model is a good fit for > a high level language. I'm very much a proponent of message passing. > Unlike shared memory, it's actually easier to do the right thing than > not. Implementing it correctly and efficiently is not easier than > doing a shared memory system though in my experience (I'm busy > implementing it on top of ithreads; yeah I'm masochist like that). > > > And we also need to stand back a little further and ask: is "threading" > > the right approach at all? Do threads work in *any* language? Are there > > better metaphors? > > > > Perhaps we need to think more Perlishly and reframe the entire question. > > Not: "What threading model do we need?", but: "What kinds of non-sequential > > programming tasks do we want to make easy...and how would we like to be > > able to specify those tasks?" > > I agree. I would prefer implicit over explicit concurrency wherever possible. I know you're speaking about the Perl interface to concurrency, but you seem to contradict yourself because message passing is explicit whereas shared memory is implicit - two different models, both of which could be used together to implement a pretty flexible system. It'd be a shame to not provide a way to both use threads directly or to fallback to some implicitly concurrent constructs. Brett -- B. Estrade
Re: threads?
On Tue, Oct 12, 2010 at 07:22:33AM -0700, Damian Conway wrote: > Leon Timmermans wrote: > > > For the love of $DEITY, let's please not repeat ithreads! > > $AMEN! > > Backwards compatibility is not the major design criterion for Perl 6, > so there's no need to recapitulate our own phylogeny here. > > The problem is: while most people can agree on what have proved to be > unsatisfactory threading models, not many people can seem to agree on > what would constititute a satisfactory threading model (or, possibly, models). > > What we really need is some anecdotal evidence from folks who are actually > using threading in real-world situations (in *any* languages). What has worked > in practice? What has worked well? What was painful? What was error-prone? > And for which kinds of tasks? > > And we also need to stand back a little further and ask: is "threading" > the right approach at all? Do threads work in *any* language? Are there > better metaphors? A more general metaphore would be asynchronous tasking, a thread being a long running "implicit" task. Other issues include memory consistency models, tasking "granularity", scheduling, and flexible synchronization options. I am coming from the OpenMP world, so a lot of this falls on the shoulders of the runtime - a clear strength of Perl IMHO. It may be worth someone taking the time to read what the OpenMP spec has to say about tasking as well as exploring tasking support on Chapel, Fortress, X10, and Cilk. PGAS based languages may also offer some inspirations as a potential alternative to threads or tasks. The only scriping language that I know that supports threading natively is Qore. I've mentioned this before. Perl's functional aspects also make it fairly easy to create concurrency without the worry of side effects, but not everyone is lucky enough to have a loosely coupled problem or not need i/o. Now how to distill what's been learned in practice into a Perlish approach? > > Perhaps we need to think more Perlishly and reframe the entire question. > Not: "What threading model do we need?", but: "What kinds of non-sequential > programming tasks do we want to make easy...and how would we like to be > able to specify those tasks?" There are something like 12 HPC "domains" that have been identified, all needing something a little different from the compiler, runtime, and platform - these do not include things for which Perl is often (ab)used. > > As someone who doesn't (need to) use threading to solve the kinds of > problems I work on, I'm well aware that I'm not the right person to help > in this design work. We need those poor souls who already suffer under > threads to share their tales of constant misery (and their occasional > moments of triumph) so we can identify successful patterns of use > and steal^Wborg^Wborrow the very best available solutions. Are you sure you couldn't use threading over shared memory? :) Cheers, Brett > > Damian -- B. Estrade
Re: Lessons to learn from ithreads (was: threads?)
On Wed, Oct 13, 2010 at 04:00:02AM +0200, Leon Timmermans wrote: > On Wed, Oct 13, 2010 at 12:46 AM, Tim Bunce wrote: > > So I'd like to use this sub-thread to try to identify when lessons we > > can learn from ithreads. My initial thoughts are: > > > > - Don't clone a live interpreter. > > Start a new thread with a fresh interpreter. > > > > - Don't try to share mutable data or data structures. > > Use message passing and serialization. > > Actually, that sounds *exactly* like what I have been trying to > implementing for perl 5 based on ithreads (threads::lite, it's still > in a fairly early state though). My experience with it so far taught > me that: > > * Serialization must be cheap for this to scale. For threads::lite > this turns out to be the main performance bottleneck. Erlang gets away > with this because it's purely functional and thus doesn't need to > serialize between local threads, maybe we could do something similar > with immutable objects. Here micro-optimizations are going to pay off. Being able to optionally define objects as structures in contiguous memory could be a useful optimization. Both for serialization and general cache-friendly cpu performance. Just a thought. > * Code sharing is actually quite nice. Loading Moose separately in a > hundred threads is not. This is not trivial though, Perl being so > dynamic. I suspect this is not possible without running into the same > issues as ithreads does. If you wanted to start a hundred threads in a language that has good support for async constructs you're almost certainly using the wrong approach. In the world of perl6 I expect threads to be used rarely and for specific unavoidably-bocking tasks, like db access, and where true concurrency is needed. Also, it should be possible to share read-only bytecode and perhaps read-only jit'd executable pages, to avoid the full cost of "reloading" modules. > * Creating a thread (/interpreter) should be as cheap as possible, > both in CPU-time as in memory. Creating an ithread is relatively > expensive, specially memorywise. You can't realistically create a very > large number of them the way you can in Erlang. Erlang has just the one kind of concurrency mechanism: the "thread" so you need to create lots of them (which Erlang makes very cheap). We're looking at two concurrency mechanisms for perl6: Heavy-weight O/S thread+interpreter pairs (as above), and lightweight async behaviours within a single interpreter (eg continuations/fibers). Those lightweight mechanisms are most like Erlang "threads". They'll be cheap and plentiful, so they'll be far less need to start O/S threads. Tim. > Leon > > (well actually I learned a lot more; like about non-deterministic unit > tests and profilers that don't like threads, but that's an entirely > different story) (Adding thread/multiplicity support to NYTProf shouldn't be too hard. I don't have the time/inclination to do it at the moment, but I'll fully support anyone who has.)
Re: threads?
On Tue, Oct 12, 2010 at 02:31:26PM +0200, Carl M?sak wrote: > Ben (>): > > If perl6 can statically (at compile time) analyse subroutines and > > methods and determine if they're reentrant, then it could > > automatically use the lightest weight threads when it knows that the > > entry sub won't have side effects or alter global data. > > I'm often at the receiving end of this kind of reply, but... > > ...to a first approximation, I don't believe such analysis to be > possible in Perl 6. Finding out whether something "won't have side > effects" is tricky at best, squeezed in as we are between &eval, > exuberant dynamism, and the Halting Problem. If one knows what variables are shared, some degree of side effect potential can be determined. But yes, in general, a tough problem. Brett > > // Carl -- B. Estrade
Re: threads? - better metaphors
On 2010-Oct-12, at 10:22, Damian Conway wrote: > What we really need is some anecdotal evidence from folks who are actually > using threading in real-world situations (in *any* languages). What has worked > in practice? What has worked well? What was painful? What was error-prone? > And for which kinds of tasks? > > And we also need to stand back a little further and ask: is "threading" > the right approach at all? Do threads work in *any* language? Are there > better metaphors? 'Channels are a good model of the external world' - Russ Cox Threads without Locks, slide 39 Perhaps the work on the 'channel' model done in Plan9 (and Inferno) will be helpful. It has many years of experience in publicly available code, libraries, and discussion archives, and verification tools. Particularly the work of Russ Cox http://swtch.com/~rsc/ Particularly Threads without Locks Bell Labs, Second International Plan 9 Workshop, December 2007 http://swtch.com/~rsc/talks/threads07/ This talk has a nice crisp overview of the issues in different models and mentions several real world applications concurrent prime sieve (by Mcllroy) file system indexer implementation publish and subscribe re-entrant IO multiplexing window systems http://swtch.com/~rsc/thread/cws.pdf <-- amazing stuff! http://video.google.com/videoplay?docid=810232012617965344 the classic 'Squinting at Power Series' - and several others (see slide 31) http://swtch.com/~rsc/thread/squint.pdf (this could be an excellent test suite of any 'threading' implementation) and extended in the work of PlanB http://lsub.org/ls/planb.html http://lsub.org/index.html#demos This model is available on many OSs in the port of Plan9 to user space http://swtch.com/plan9port/ and in C based libthread that builds multiple-reader, multiple-writer finite queues. There is a lot to like and borrow from Plan9, including the 9P2000 protocol as a core organizing meme http://9p.cat-v.org/faq The 'Spin' verification tool and it's history are *very* interesting also http://swtch.com/spin/ Note that many of the people doing 'go' were the ones that did Plan9 Regards, Todd Olson PS I'd really like to have their channel model available in Perl6 Many things I'd like to model would work well with channels I have (unpublished) Perlish syntax to lay over channels PPS Russ has also done some nice work on regular expression engines http://swtch.com/~rsc/regexp/
