| 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.
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.
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.
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]]
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?
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
Before you buy.
|
| Wed, 18 Jun 1902 08:00:00 GMT |
|
| |
Page 1 of 2
|
[ 25 post ] |
|
Go to page:
[1]
[2] |
|
