TIMTOWTDI vs. ithreads

nothingmuch has asked for the wisdom of the Perl Monks concerning the following question:

Something that has always struck me as odd is that ithreads, the one true threads implementation for perl, is pretty closed minded.

Personally I liked the old Thread way of doing it better. I prefer having everything shared by default, because i find the process of explicitly sharing tedious and more error prone than making sure I don't get into race conditions. Some would argue that it's better, because unshared data will be barked about, but deadlocks aren't really detectible. So what?

What about a third way of doing it? No variables are shared by default, but data is: you can put a reference in a shared variable, and dereference any length of nested structures from it, in another thread.

And so on, and so forth.

So why isn't there another way? Is there going to be another way? Are ithreads going to become lax enough in the future to allow there to be another way without there really being another way?

Here are some other ways I know, but they aren't really satisfactory:

Event and it's friends for event loops. You get the illusion of concurrency.
forks - so close to ithreads conceptually (from a programming perspective), that it's a drop in replacement. It really stresses the fact that ithreads are not really what I want from threads...
Thread - depracated. I don't want to write new code for a feature which I know is going away sometime soon.
Coro - Not really threads, implements it all in user space. Perhaps as good as it gets? Kind of sucky, since my work horses are all SMP.

So, given only these alternatives, and only one (real) way to do it, what is a boy to do?

-nuffin
zz zZ Z Z #!perl

Comment on TIMTOWTDI vs. ithreads

Replies are listed 'Best First'.
Re: TIMTOWTDI vs. ithreads by diotalevi (Canon) on Sep 14, 2004 at 15:19 UTC
You neglected to mention POE in your list of alternatives. I use it in favor of threads because it is stable, unlike threads. It manages to do all the work inside a single process with cooperative multitasking. Nothing really runs simultaneously but it can look like it.	[reply]
Re^2: TIMTOWTDI vs. ithreads by nothingmuch (Priest) on Sep 14, 2004 at 17:32 UTC
I sort of counted it under Event and friends, because as far as I know it is an event loop based framework, right? I could be ignorant, not having used it (yet). Is it substantially different? -nuffin zz zZ Z Z #!perl	[reply]
Re^3: TIMTOWTDI vs. ithreads by diotalevi (Canon) on Sep 14, 2004 at 22:37 UTC
Yes, that's a fair characterization. I'd have disappeared Event from your list and kept POE had I needed to remove one. I never got Event to compile so AFAICT, it isn't "current." POE's the thing these days especially when you don't want to involve all the requisite bugs and magic of threads or are on a Windows machine. PS, Windows installs are the most common platform for perl to be on these days.	[reply]
Re: TIMTOWTDI vs. ithreads by BrowserUk (Patriarch) on Sep 14, 2004 at 16:59 UTC
Personally, I prefered the concept of Thread too, but when you look at the problems it involves with perl's fat internal data structures and the lack of re-entrancy, it was pretty near impossible to make them stable. I've become quite used to the way iThreads work, and find them infinitely preferable to the alternatives. Event loops, like Event and POE mean breaking up simple pieces of code into complicated and error prone state machines and relying on a raft of globals to store state. I very rarely find the need to explicitely use the locking and sharing primitives. Using Thread::Queue to communicate between thread relieves me of that burden and makes most threaded programs I write very simple. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon	[reply]
Re: TIMTOWTDI vs. ithreads by ambrus (Abbot) on Sep 14, 2004 at 16:38 UTC
I don't think that's a good idea in perl. If all data would be shared, than perl would have to lock any piece of data it reads or writes, and that would be a major speed penalty (and maybe memory too, I'm not sure). Also if data are shared than the memory management has to be shared too, because any thread might have to free any data (when it finds that the reference count has dropped to zero) and that would also be a minor slowdown.	[reply]
Re^2: TIMTOWTDI vs. ithreads by nothingmuch (Priest) on Sep 14, 2004 at 17:43 UTC
How is this avoided with interpreter threads? They can, after all, share data... I reckon that since it's a special case it might be handled specially, whilst other data is not? Furthermore, today starting a thread is an enourmous performance penalty, because all non shared data is copied. Unlike forking, where we have copy-on-write (for the curious- it's very efficient, because the kernel simply marks all memory pages as readonly, causing write operations to raise an exception from the MMU, to which the kernel responds to making a new copy of the page which the writing process can work on), there is no optimisation of the process. The main advantage I'm looking for in threads is to gain performance due to concurrency on SMP platforms, for small tasks. Starting a thread needs to be cheap for this to be effective. I think a tradeoff of some continuous speed penalty for an efficient startup time, should at least be a choice. I'll go looking for some reading material, but I'm sick and too tired to concentrate for any reasonable length of time, so I doubt I can introduce any worthwhile discussion to this thread. -nuffin zz zZ Z Z #!perl	[reply]
Re^3: TIMTOWTDI vs. ithreads by ambrus (Abbot) on Sep 14, 2004 at 17:59 UTC
When you use ithreads properly, you create the threads soon, when there are only very few data in the heap, and you use as few shared data as possible. When ithreads is used this way, it should be reasonably fast. This means that the ithreads model is not ideal for some tasks you could normally do with threads. Ithreads are, however, very good for tasks where the threads do almost independent work, such as fork emulation or servers handling multiple connections. It is not suited for other tasks, such as tasks with heavy paralel computation imo. Thus, I aggree with your original post in that ithreads might not always be what you want. I do not know about any high level language supporting a thread model similar to for example pthreads, probably because that would make the interpreter unstable when you do not uses locks properly (5005Threads were like that iirc). If you need such threads, you migt want to look at other languages than Perl. Ruby has continuation-based threads, that means of course that it uses only one cpu at a time.	[reply]