Author |
Message |
Ian Meikl #1 / 25
|
 Multi-threading
Hello, I have a question about multi-threading in Smalltalk. From what I can see only Smalltalk MT provides true OS level multi-threading support. Why is this ?? From what I can gather Java has true OS level multi-threading support. I see not having this as a resitiction when desciding to build a server application in Smalltalk. I personally feel Smalltalk is perfectially suited to build server side applications, however without true OS level multi-threading, you would not be able to scale your application on SMP systems. I see this as a major hindrance to the future of Smalltalk. So can someone please explain to me why it is still lacking in the most popular of Smalltalk dialects. Many thanks Ian
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
James A. Robertso #2 / 25
|
 Multi-threading
Quote:
> Hello, > I have a question about multi-threading in Smalltalk. > From what I can see only Smalltalk MT provides true > OS level multi-threading support. > Why is this ?? > From what I can gather Java has true OS level > multi-threading support. > I see not having this as a resitiction when desciding to build > a server application in Smalltalk. I personally feel Smalltalk is > perfectially suited to build server side applications, however without > true OS level multi-threading, you would not be able to scale > your application on SMP systems.
Not really the case. VW (and VA) have support for OS threads when making calls outside of Smalltalk. So any API call can be made to spawn an OS thread. This allows for a highly scalable solution. Using Distribution (DST or Opentalk) one can build a farm of servers that load balance as well - I have customers doing this to good effect. Smalltalk MT does use native threads, but is Windows specific. Quote: > I see this as a major hindrance to the future of Smalltalk. So > can someone please explain to me why it is still lacking in the > most popular of Smalltalk dialects.
It's not at all easy to build in a cross platform product in a stable fashion. Note that Java has backed off on making all classes thread safe; it turned out that it slowed things down a <lot>. Also, threading may not help you much on a single processor system; one can scale more easily (and more reliably as well) by building a server farm than by deploying an SMP box. In a farm, if one box ges off, you still have a server. With an SMP, if that box goes down, you don't. Quote: > Many thanks > Ian
-- James A. Robertson Senior Sales Engineer, Cincom
<Talk Small and Carry a Big Class Library>
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
Alan Knig #3 / 25
|
 Multi-threading
Even on an SMP box you may be better off with separate processes rather than threads. There are a fair number of pieces of software in this world that use processes rather than threading and nevertheless manage to scale reasonably well. e.g. Apache
Quote:
>> Hello, >> I have a question about multi-threading in Smalltalk. >> From what I can see only Smalltalk MT provides true >> OS level multi-threading support. >> Why is this ?? >> From what I can gather Java has true OS level >> multi-threading support. >> I see not having this as a resitiction when desciding to build >> a server application in Smalltalk. I personally feel Smalltalk is >> perfectially suited to build server side applications, however without >> true OS level multi-threading, you would not be able to scale >> your application on SMP systems. >Not really the case. VW (and VA) have support for OS threads when >making calls outside of Smalltalk. So any API call can be made to spawn >an OS thread. This allows for a highly scalable solution. Using >Distribution (DST or Opentalk) one can build a farm of servers that load >balance as well - I have customers doing this to good effect. >Smalltalk MT does use native threads, but is Windows specific. >> I see this as a major hindrance to the future of Smalltalk. So >> can someone please explain to me why it is still lacking in the >> most popular of Smalltalk dialects. >It's not at all easy to build in a cross platform product in a stable >fashion. Note that Java has backed off on making all classes thread >safe; it turned out that it slowed things down a <lot>. Also, threading >may not help you much on a single processor system; one can scale more >easily (and more reliably as well) by building a server farm than by >deploying an SMP box. In a farm, if one box ges off, you still have a >server. With an SMP, if that box goes down, you don't. >> Many thanks >> Ian >-- >James A. Robertson >Senior Sales Engineer, Cincom
><Talk Small and Carry a Big Class Library>
-- Alan Knight [|]
Cincom Systems
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
Lex Spoo #4 / 25
|
 Multi-threading
Quote:
> Hello, > I have a question about multi-threading in Smalltalk. > From what I can see only Smalltalk MT provides true > OS level multi-threading support. > Why is this ?? > From what I can gather Java has true OS level > multi-threading support. > I see not having this as a resitiction when desciding to build > a server application in Smalltalk. I personally feel Smalltalk is > perfectially suited to build server side applications, however without > true OS level multi-threading, you would not be able to scale > your application on SMP systems. > I see this as a major hindrance to the future of Smalltalk. So > can someone please explain to me why it is still lacking in the > most popular of Smalltalk dialects.
Someone posted an extremely similar query not long ago. Anyway, here goes. First, what is "true" threading? I suppose you mean preemptive? And what does "OS-level" matter? Computers are progammed with encapsulated software nowadays; it should be irrelevant whether you are talking to the OS directly, or to a virtual machine, or to a virtual machine embedded in another virtual machine. High-level code should simply make requests to the next-lower substrate for things it wants. Anyway, Smalltalk does in fact have preemption, even if it's not Unix-like. In fact, Smalltalk's threading behavior, including preemption, is quite well defined and is the same model used by most of those most serious of threaders, real time operating systems. Java is hardly a model to aspire to--it's htreading model is something like "uh, you have something called threads. And, uh, maybe they swap automatically every once in a while. But then again, maybe they don't". A portable Java program can't make many assumptions about the threading model that it will run on; in fact, it's a good idea to avoid threads in Java if you want portability. Overall, perhaps you are writing a threaded application in Smalltalk and having trouble? If so, you might try posting details about it and seeing what the newsgroup lurkers can come up with. But to suggest one generalization, be sure to play with thread priorities. Thread priorities allow you to mark some threads as more deserving of CPU than others; when there is contention over the CPU, a thread with a higher priority will always win. -Lex
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
Richard MacDonal #5 / 25
|
 Multi-threading
Quote: > Overall, perhaps you are writing a threaded application in Smalltalk > and having trouble? If so, you might try posting details about it and > seeing what the newsgroup lurkers can come up with. But to suggest > one generalization, be sure to play with thread priorities. Thread > priorities allow you to mark some threads as more deserving of CPU > than others; when there is contention over the CPU, a thread with a > higher priority will always win.
There is no multitasking in the Smalltalk thread model, but it is easy to simulate: Just a few lines of code.
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
Timo Saarine #6 / 25
|
 Multi-threading
Quote:
> > I see not having this as a resitiction when desciding to build > > a server application in Smalltalk. I personally feel Smalltalk is > > perfectially suited to build server side applications, however without > > true OS level multi-threading, you would not be able to scale > > your application on SMP systems.
As far as I know, isn't Smalltalk too slow for server side? I suppose that you have to scale the system quite much before you overcome poor performance. -Timo
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
jaro.. #7 / 25
|
 Multi-threading
Quote:
>As far as I know, isn't Smalltalk too slow for server side? I suppose >that you have to scale the system quite much before you overcome poor >performance.
Visit www.ezboard.com and see for yourself. That's a VisualWorks webserver doing the work.... James A. Robertson Senior Sales Engineer, Cincom
<Talk Small and Carry a Big Class Library> Quote: >-Timo
-- James A. Robertson Senior Sales Engineer, Cincom
<Talk Small and Carry a Big Class Library>
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
David Shaffe #8 / 25
|
 Multi-threading
Maybe I'm somewhat off-topic here but I'm trying to get a better understanding of VW threading and server models...anyway, why are the Delay>>forMilliseconds: calls needed in the method below (from the Wiki server's NetworkServer class)? This gives me a bad feeling that race conditions could develop in a server under heavy load but, then again, I really don't know why they're there. I'm coming from a Java/C/C++ background and here's my understanding of server-side application architectures: 1) using select() to wait for requests from all active client sockets an the listening socket 2) using threads or child processes to handle client requests while one dedicated thread listens for connections 3) using interrupt driven IO and queuing client requests inside the interrupt handler 4) using polling (hopefully supported by the OS via POSIX poll() function) Can anyone tell me the VW equivalents of these? What does the NetworkServer class use? I assume that "child processes" in ST would not be actual OS processes (although, of course, they could be but I think the startup times would be prohibitive unless a process pool was used) but ST Process instances. What issues arrise when one ST Process instance blocks on a socket read? For example, does the whole ST virtual machine block (an OS-blocked read) or does the VW use "THAPI" type calls so that the VM can continue? I could/should experiment with some of this but I'd appreciate someone giving me a reference point with regards standard sockets application architectures. Thanks! David NetworkServer>>serverLoop [(Delay forMilliseconds: 20) wait. self socketIsActive] whileTrue: [ [sessionManager manageSessionForServer: self andClient: listeningSocket accept] on: listeningSocket errorReporter errorSignal do: [:ex | self log: 'Failed in serveLoop: ' , ex messageText. (Delay forMilliseconds: 100) wait. ex return]]
Quote:
> >As far as I know, isn't Smalltalk too slow for server side? I suppose > >that you have to scale the system quite much before you overcome poor > >performance. > Visit www.ezboard.com and see for yourself. That's a VisualWorks webserver > doing the work.... > James A. Robertson > Senior Sales Engineer, Cincom
> <Talk Small and Carry a Big Class Library> > >-Timo > -- > James A. Robertson > Senior Sales Engineer, Cincom
> <Talk Small and Carry a Big Class Library>
Sent via Deja.com http://www.deja.com/ Before you buy.
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
Marten Feldtman #9 / 25
|
 Multi-threading
David Shaffer schrieb: Quote: > understanding of VW threading and server models...anyway, why are the > Delay>>forMilliseconds: calls needed in the method below (from the Wiki > server's NetworkServer class)? This gives me a bad feeling that race
Just a guess: perhaps you won't see the log message then ? Marten
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
David Shaffe #10 / 25
|
 Multi-threading
I don't think that's it since a wait occurs in the main loop even if no error is encountered.
Quote:
> David Shaffer schrieb: > > understanding of VW threading and server models...anyway, why are the > > Delay>>forMilliseconds: calls needed in the method below (from the Wiki > > server's NetworkServer class)? This gives me a bad feeling that race > Just a guess: perhaps you won't see the log message then ? > Marten
Sent via Deja.com http://www.deja.com/ Before you buy.
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
Marten Feldtman #11 / 25
|
 Multi-threading
David Shaffer schrieb: Quote: > I don't think that's it since a wait occurs in the main loop even if no > error is encountered.
Sorry, I looked at the other one in the source .... Marten
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
Marten Feldtman #12 / 25
|
 Multi-threading
David Shaffer schrieb: Quote: > NetworkServer>>serverLoop > [(Delay forMilliseconds: 20) wait. > self socketIsActive] whileTrue: > [ > [sessionManager manageSessionForServer: self > andClient: listeningSocket accept] > on: listeningSocket errorReporter errorSignal > do: > [:ex | > self log: 'Failed in serveLoop: ' , ex messageText. > (Delay forMilliseconds: 100) wait. > ex return]]
Then another guess: If "(Delay forMilliseconds: 20) wait" would not be inserted and "self socketIsActive" is just a poll to query the socket how would the other Smalltalk processes would be able to get computing resources ? The rest of the code does not seem to have any code making a process switch. This process now is suspended for 20 milliseconds and now all the worker task become alive and can to the actual work ... Actually you may be able to handle up to 50 new connections per seconds -- not that bad ? But that is just a guess ... :-) Marten
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
Alan Knig #13 / 25
|
 Multi-threading
Quote: >Maybe I'm somewhat off-topic here but I'm trying to get a better >understanding of VW threading and server models...anyway, why are the >Delay>>forMilliseconds: calls needed in the method below (from the Wiki >server's NetworkServer class)? This gives me a bad feeling that race >conditions could develop in a server under heavy load but, then again, I >really don't know why they're there.
I'm not really an expert, but my best theory is that they're unnecessary. See below. Quote: >I'm coming from a Java/C/C++ background and here's my understanding of >server-side application architectures: > 1) using select() to wait for requests from all active client sockets >an the listening socket > 2) using threads or child processes to handle client requests while >one dedicated thread listens for connections > 3) using interrupt driven IO and queuing client requests inside the >interrupt handler > 4) using polling (hopefully supported by the OS via POSIX poll() >function) >Can anyone tell me the VW equivalents of these? What does the >NetworkServer class use? I assume that "child processes" in ST would >not be actual OS processes (although, of course, they could be but I >think the startup times would be prohibitive unless a process pool was >used) but ST Process instances. What issues arrise when one ST Process >instance blocks on a socket read? For example, does the whole ST >virtual machine block (an OS-blocked read) or does the VW use "THAPI" >type calls so that the VM can continue?
I'm not sure what the deep-down mechanism is, but when an ST process blocks on a socket read it blocks only the process, not the entire VM. This is easy to see by forking off a Smalltalk process that waits on a socket and noting that everything else continues to work. See, for example the SocketAccessor class methods in the "examples" category. If you block the UI process then the UI blocks, of course, but if you fork it into the background it works just fine. There should be no need to have a delay in there. There's no delay in the VisualWave server loop, and there's no delay in the modified WikiWorks that Anthony Lander did. Peter Hatch suggests: I have a feeling that the Delays were added as a fix for BSD socket errors that can be signaled under high-load conditions or by using improperly configured listener sockets. My only other theory is that this is some kind of attempt to load balance between the main server loop and the processes doing the actual work. The main loop runs at a higher priority than the session processes that it spawns. If you didn't have the delay, and there were lots and lots of requests coming in such that the server loop never blocked, then you could conceivably starve the spawned processes that were servicing the requests, endlessly spawning more and more of them without ever servicing any. By putting in the delay you could ensure that there was a maximum rate at which new requests were spawned. If this is the reason, I would think there are better, or at least clearer, ways to accomplish that. -- Alan Knight [|]
Cincom Systems
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
 |
David Shaffe #14 / 25
|
 Multi-threading
Thanks for your reply. I removed the #wait call and found that under VW the Wiki worked fine and I was able to browse around the image while web page requests came in. That is, the rest of the image remained responsive while the server was blocked on the socket.
Quote: > I'm not really an expert, but my best theory is that they're unnecessary. > See below. > I'm not sure what the deep-down mechanism is, but when an ST process blocks > on a socket read it blocks only the process, not the entire VM. This is > easy to see by forking off a Smalltalk process that waits on a socket and > noting that everything else continues to work. See, for example the > SocketAccessor class methods in the "examples" category. If you block the > UI process then the UI blocks, of course, but if you fork it into the > background it works just fine. > There should be no need to have a delay in there. There's no delay in the > VisualWave server loop, and there's no delay in the modified WikiWorks that > Anthony Lander did. > Peter Hatch suggests: > I have a feeling that the Delays were added as a fix for BSD socket > errors that can be signaled under high-load conditions or by using > improperly configured listener sockets. > My only other theory is that this is some kind of attempt to load balance > between the main server loop and the processes doing the actual work. The > main loop runs at a higher priority than the session processes that it > spawns. If you didn't have the delay, and there were lots and lots of > requests coming in such that the server loop never blocked, then you could > conceivably starve the spawned processes that were servicing the requests, > endlessly spawning more and more of them without ever servicing any. By > putting in the delay you could ensure that there was a maximum rate at > which new requests were spawned. If this is the reason, I would think > there are better, or at least clearer, ways to accomplish that. > -- > Alan Knight [|]
> Cincom Systems
Sent via Deja.com http://www.deja.com/ Before you buy.
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
|
Page 1 of 2
|
[ 25 post ] |
|
Go to page:
[1]
[2] |
|