Re: Where is concurrency going? Is Perl going there?

[BrowserUk]

Parrot, threads & fears for the future.

Conclusion: "The future is threaded." - I respectfully disagree.(*)

Respectfully, what is it that you are disagreeing with?

Threads; many forms and many abstractions

With the exception of POE and similar event-driven processing, all of the concurrency mechanisms you cite use threads. That is, multiple, concurrent, in-process, paths of execution. They may be 'user threads' (aka. cooperative scheduling), or 'kernel threads' (aka. preemptive scheduling), or some hybrid that uses an in-process scheduler to distribute the kernel-scheduled time-slices allocated to the process, to the threads within the process.

Or they can be some combination of the two (or more) of those, as exemplified by Win32 Fibres, where a process can have multiple paths of execution, with some scheduled preemptively by the kernel, and others scheduled cooperatively.

With the noted exception, all of the concurrency mechanisms you've cited do, or can, use threads as their underlying mechanism. So to disagree with the statement that "The future is threaded", is to disagree that any of those mechanisms have a place in the future--except the 'do a bit and check, do a bit and check--all state managed through globals' event-driven, state machine architecture.

Head in the sand, looking back futurism

If that is your conclusion, then stop reading here, and we'll see some time in the future. Likewise if you are in the thread is spelled "f-o-r-k" camp. If however, you see one or more of those other mechanisms as having a place in the future, then read on.

Misunderstanding/miscommunication

I think that you, in concert with many others that read my article, concluded that by 'threads', I meant threads as exemplified by the barely encapsulated POSIX pthreads api. Nothing could be further from the truth. But the responsibility for the misunderstanding probably lies with me. However, I would point out an extract from that article:

Much of the resistance/reluctance to utilise threading can be attributed to a single factor--there are few if any good tools available.

• Most languages--that the majority of people use--either do not support threading at all, or support it as an afterthought. And then only at the lowest level.
• There are few good abstractions of shared state. If every program still had to deal with disk-bound data by directly manipulating physical blocks and free-space chains, very few programs that manipulate file-based data would exist--that's most programs in existence. Today's ubiquitous hierarchical filesystems make it seem as if there was never any other way, and that tends to imply that they are perfect. But we also have RDBMSs, which are most definitely not hierarchical, and not file-based, (Although they often live on hierarchical filesystems.).
• Most of todays programming tools--compilers, interpreters, editors, debuggers, runtime libraries etc.--are the latest evolutions of the same tools that go back years., In many cases, decades.

And this post which screamed: "Threads Are Primitive And Should Die!"; but went on to qualify that with: "That's why I heartily support the death of threads in HLLs!".

My response to which I'll include here verbatim.

Funnily enough, I agree. I've been banging on about that for a couple of years. I think I even recall having a conversation with you about it by email 2 or more years ago.

Parrot is not a high level language.

If the HLL Perl6, is to provide for user transparent threading semantics; and if Perl6 is to run atop the Parrot VM; then Parrot has to do threads. And be written from the ground up to do threads well.

Abomination

So you see, I think that exposing the pthreads api (and similar low-level, shared-state-memory-and-locks, expressions of threads), to user level, high level languages is an abomination.

Indeed, the whole point of my article was to draw attention to my perception that Parrot was simply going to emulate the Perl 5 practice of exposing the pthreads api to its supported languages, and Perl 6 in particular. And that they were likely to make the same mistakes as Perl 5 by:

1. Exposing those low-level features to the HLL users.
2. Make the same mistake of equating 'thread' == 'interpreter'.
3. Make the same mistake of attempting to emulate the fork-like mode of operation whereby the current thread is cloned at the point of thread creation

And my hope in doing so was that it might cause the whole subject of threading, within Perl 6 but more importantly within Parrot, to be re-visited with a clearer and more analytical approach than I had perceived as having happened up to that point. The future will determine whether I was successful in that goal.

Perl 5 iThreads

Perl's iThreads are actually a very bold, and partially successful move away from the all-implicitly-shared threading model. Its 'only explicitly shared' model removes a whole class of accidentally shared errors from the table. That bold step means that a huge percentage of legitimately concurrent programs are as simple to write (in Perl 5, using ithreads), as writing two separate scripts. Debug each separately and when you put them together, they 'Just work'. Run multiple copies of either component and be assured they will still just work.

And when they need to communicate, use a simple to understand, easy to use, safe, conceptually clean and almost trivially programmed abstraction (Thread::Queue) and almost anyone can program a threaded application with ease. And without having to pay any consideration to the dreaded, threaded nightmares of deadlocking, priority inversion et al.

Easy, when done right

Used this way, by avoiding most of the low-level components of the pthreads (and other) apis, iThreads + Thread::Queue bring the potential of concurrency to a wide range of the huge and growing numbers of joe-average programmers for whom programming is just a means to an end, but that wish to capitalise on the potential of their, now ubiquitous, multi-core/multi-cpu, commodity hardware.

As such, they are a remarkable achievement, for which those that initiated them, and those that have gradually debugged them, are worthy of immense praise for their insights and dedications.

Their main limitations arise from two (IMO) mal-features:

1. The interpreter == thread conflation.
2. The attempt to provide a 'fork-like' mode of operation by cloning the state of the current interpreter.

At the kernel level, threads consist of

1. A stack pointer.
2. A set of ghost registers, including program counter.

They are very lightweight. The memory requirements for internal data-structures are trivial. Creating them and switching between them is very fast.

The mal-features above mean that instead of iThreads being lightweight and fast, they are slow and heavy. It is the replication/perpetuation of these mal-features that I hoped to prevent by posting my article.

I understand why iThreads evolved the way they did. In part to provide a fork emulation on win32, to enhance the portability of Perl; in part because retro-fitting threading to a perl, code that was never designed for it and therefore has inherent dependencies on non-reentrant code and global data-structures.

But Perl 6 & Parrot have the opportunity to avoid all of that.

And if in-process concurrency (threading, of any of the forms you mentioned above minus the exception), is to be available in Perl 6 and other languages supported by Parrot, then threading has to be explicitly and ubiquitously considered and programmed for in the design and implementation of both.

21st Century HLL languages

It is my belief that FP languages--in particular, pure FP languages--will not make the transition to wide-spread, commercial and non-professional-programmer usage.

Ie. Perl's niche.

Their abstractions are too onerously academic; their type systems too demanding; their notation and formulation too abstract and pedantic; their deep analysing compilers too big, too heavy and too laborious. Within their niche, they will see growth in use, but this will be nothing as compared to the explosive growth in the numbers of non-academic, non-professional programmers writing code as a means to an end to achieving their primary rolls.

I believe that the language(s) that these people will turn to, to get their work done, will be a dynamic, loosely typed, approachable language with familiar, comfortable abstractions. And with the instant gratification of immediate feedback that interpreted languages give. And without the need for rigorous discipline, nor the steep, laborious, all-consuming learning curve that FP languages demand.

The future is threaded

So, like it or not, head in the sand or not, the future will be threaded. The only real discussion is what abstractions will be wrapped around threads, and their nemesis: shared state. And what language(s) will encapsulated those abstractions, and transparently combine them with an appropriate set of other language paradigms, such that joe-average application programmer can utilise them with impunity.

The future is threaded. we just may not (hopefully will not) perceive it as such. Whether Perl (6) will be the language of choice for utilising them, time will tell.

In any case, I predict that whichever dynamic, interpreted, 'relaxed typed'(TM) language provides a reasonably performing, safe, high level abstraction around shared-state concurrency, will be lingua-franca of the non-professional-programmer, coders. That vast and growing group of people in a wide and growing range of occupations for whom programming is just another tool in achieving their occupations primary goal.

(*)As the author of that article, I feel it incumbent upon me to respond--though I may delay posting this until this thread has a) received other replies, so I can see 'which way the wind blows'; b) until it has moved off the front page.

Update: I decided against waiting. This either stands or falls on it's own merits regardless of what others choose to say; or their perceptions of my reasons for posting it!

[erroneousBollock]

With the exception of POE and similar event-driven processing, all of the concurrency mechanisms you cite use threads. That is, multiple, concurrent, in-process, paths of execution. They may be 'user threads' (aka. cooperative scheduling), or 'kernel threads' (aka. preemptive scheduling), or some hybrid that uses an in-process scheduler to distribute the kernel-scheduled time-slices allocated to the process, to the threads within the process.

I guess I didn't get that impression on my first visit to your article... please accept my apology.

I also agree that, in general, FP constructs and robust type-systems will not make it the mainstream (as long as comp-sci is treated as voodoo rather than a branch of mathematics. :)

C# and Perl6 are however getting *some* form of type-inference... in my view, a step in the right direction.

We could probably "bolt-on" a lot of the concurrency paradigms (emulating them with threads and locks), but I think that most users will stumble because of reliability problems created through lack of type-guarantees.

I honestly don't believe there will be a "reliable, safe, high-level abstraction" for concurrency until we have at least type-annotations (visible or not) for side -effecting code that can be picked up in type-inference.

[renodino]

And when they need to communicate, use a simple to understand, easy to use, safe, conceptually clean and almost trivially programmed abstraction (Thread::Queue) and almost anyone can program a threaded application with ease.

Oblig. and shameless plug for Thread::Apartment, which hopefully goes even further to ease the process (tho, admittedly, its still a bit warty).

Alas, the current threads::shared creates a bit of a barrier to large scale threading (shared nothing/MP or otherwise) due to the global interpretter lock. But an alternative is being worked on. And while current ithreads is a burden, some of that could be alleviated by iCOW - if ever implemented.

I won't comment on Perl 6. I have problems to solve last year, and can't wait for it. Perl 5 is quite capable of concurrency, be it threaded or otherwise.