Damian, I use threads in C++ a lot in my day to day job. We use an in-house library which isn't much more than a thread class which you inherit from and give a Run method to, and a load of locks of various (sometimes ill-defined) kinds.
Let me say: it's not good. Threads with semaphores and mutexes and all that are just horrible, horrible things. It's probably not helped at all by how C++ itself has no awareness at all of the threading, so there are no hints in the code that something runs in a particular thread, you can't put lock preconditions on functions or data structures or anything like that... I'm not sure what a better model is, but what I'd like to see is something which: - can enforce that certain bits of data are only accessed if you have certain locks, at compile time - can enforce that certain bits of code can only be run when you have certain locks, at compile time - can know that you shouldn't take lock B before lock A if you want to avoid a deadlock - uses a completely different model that nobody's probably thought of yet where none of this matters because all those three things are utterly foul I always liked Software Transactional Memory, which works very nicely in Haskell - but not for all solutions. Whatever concurrency model Perl 6 might support, it's probably going to need more than one of them. Since the language is so extensible, it may be that the core should only implement the very basic primitives, and then there are libraries which provide the rest - some of which might ship alongside the compiler. I don't know, but I do not want people to end up having to count semaphores and verify locking integrity by eye because it's really, truly horrible. I did read a bit about Go's mechanism, and it did look interesting. Some systems are very well-modelled as completely independent processes (which might be threads) throwing messages at each other... Actually something that's very nice as a mental model for server-type systems is a core routine which responds to a trigger (say, a new connection) by spawning a new thread to handle it, which is the only thing which handles it, and maybe uses something like channels to interact with any global data store that's required. For that though you need cheap thread creation or easy thread pool stuff, and you need to have a global data model which isn't going to completely bottleneck your performance. I'm totally rambling now, but I do get the distinct impression from all my experience that safe concurrency is very difficult to do quickly in the general case. Of course, the safest concurrency boils down to sequencing everything and running it all on one core... On 12 October 2010 16:25, <philippe.beauch...@bell.ca> wrote: > Although anecdotal, I've heard good things about Go's "channel" mechanism as > a simple lightweight concurrency model and a good alternative to typical > threading. Channels are first-class in the language and leverage simple > "goroutine" semantics to invoke concurrency. > > > --- Phil > > > > -----Original Message----- > From: thoughtstr...@gmail.com [mailto:thoughtstr...@gmail.com] On Behalf Of > Damian Conway > Sent: October 12, 2010 10:23 AM > To: perl6-language@perl.org > Subject: Re: threads? > > 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? > > 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?" > > 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. > > Damian > On 12 October 2010 16:25, <philippe.beauch...@bell.ca> wrote: > Although anecdotal, I've heard good things about Go's "channel" mechanism as > a simple lightweight concurrency model and a good alternative to typical > threading. Channels are first-class in the language and leverage simple > "goroutine" semantics to invoke concurrency. > > > --- Phil > > > > -----Original Message----- > From: thoughtstr...@gmail.com [mailto:thoughtstr...@gmail.com] On Behalf Of > Damian Conway > Sent: October 12, 2010 10:23 AM > To: perl6-language@perl.org > Subject: Re: threads? > > 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? > > 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?" > > 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. > > Damian >
