David,
But, I do read, and keep track of what things get mentioned over time, and I've noticed comments going by that seem to imply that they are like "green threads" in Java, meaning that I/Os sometimes hang them up, that sort of thing. That's not something I want in a thread system. I also left one item off the list, which is that it's nice if the threads actually use multiple processors on a multiple processor machine.
Correct on both accounts. Threads are green threads and they don't make use of multiple processors. While I can't speak for MP systems I've long thought about solutions to make all I/O non-blocking. Unfortunately, this is not exactly simple to do in a cross-platform way.
Remember, this is in the context of grumbling at Apple for going with Java instead of Squeak, and Java's support for threads, though not perfect, is not terrible. Apple builds multiprocessors, and I've been using an MP PC for the last five years.
I didn't even listen to this grumbling about Apple and Java. I was interested in pointing out some of the positive aspects of Squeak in the area of threads; I was certainly not trying to make anybody else look bad (as if there was any need to ;-)
[Mind you, if I take my measures (which I ran across a variety of ST implementations) if it comes to parallelism Squeak beats the hell out of all existing Smalltalks. Wanna beat VisualWorks by a factor of 100?! Just give it a few thousand threads to deal with ;-]
This says (to me) that you're not using more than one processor. That's going to count against Squeak in some cases. Multiprocessor sync, even when things go well, requires some global knowledge, and that's costly (something like 10 memory bus cycles on a Pentium, was the figure I saw once).
Except, you know what -- I'll bet you've got code written already that assumes that locks are very cheap, and that would change if you went to a "proper" MP-using implementation. I think Java had to deal with this -- early Java was interpreted, and for a while used only simple "green" threads, and all the useful datastructures (StringBuffer, Hashtable, Vector) were synchronized on every operation. That got noticeably painful and slow when things had to work on an MP, and lo-and-behold, unsynchronized versions of Vector and Hashmap appeared. It's now one of the standard Java performance gotchas -- "oh, you used the synchronized data structures when you didn't need to, and it was slow". Is that something you want for Squeak?
Most certainly not. But I'm interested if you got some data points on how the performance shifted when switching away from the green threads. Are there any publications on this?
So, I don't really know the right answer here, but you might want to think about this one thing carefully before you take the MP plunge. Maybe you don't want to do it -- truly concurrent programming is noticeably harder than the sequential kind, even when sequential programming is simulating concurrent programming.
Well, I don't know. My feeling about this is that concurrency isn't necessarily harder if the high-level abstractions support it well. Looking at stuff like E, Mozart, ToonTalk and similar systems (which sometimes do require a new look at what it means to write a program) I can't say that the (usually hidden) concurrent aspects are harder to understand than any control structures in "sequential languages". The biggest problem with concurrency in non-concurrent languages is the absence of high-level concurrent constructs supporting the operations in a "natural" way.
Cheers, - Andreas