Please help, question regarding threads 
Author Message
 Please help, question regarding threads

I am somewhat new to threaded applications so am hoping someone can help
give me a little advice.

I am working on a server-oriented application which is threaded, each
connection to the server creates a new thread and many various custom class
objects are loaded per thread, some of them containing a very large amount
of data.

I am worried about scalability, does using class variables for storing the
data prevent a copy from being produced (loaded) once in each thread? That
is if the data is stored in class variables within their respective
objects, is there only one copy in memory that is shared among the various
threads that are running?

Are there other issues to consider regarding scalibility?

Thank you for whatever help and advice you may offer!
-Andy

______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.*-*-*.com/
      <><><><><><><>   The Worlds Uncensored News Source   <><><><><><><><>



Mon, 21 Mar 2005 15:02:41 GMT  
 Please help, question regarding threads
Hello Andrew,


AC> I am worried about scalability, does using class variables for storing the
AC> data prevent a copy from being produced (loaded) once in each thread? That
AC> is if the data is stored in class variables within their respective
AC> objects, is there only one copy in memory that is shared among the various
AC> threads that are running?

yes. ruby threads are very simple and light. it is close to just
switching "program counter" between several locations and no more.
data can be made local to the thread only by calling method or creating
closure (standard ruby ways to make local data) and class data is common for all threads:

class A
  def A.set(x)

  end
  def A.get

  end
end

A.set(1)
p A.get
Thread.new { A.set(2) }.join
p A.get

--
Best regards,



Mon, 21 Mar 2005 15:52:48 GMT  
 Please help, question regarding threads

Quote:

> I am somewhat new to threaded applications so am hoping someone can help
> give me a little advice.

The world of concurrent programming is vast. This little post is far
from describing that world.

Quote:
> I am working on a server-oriented application which is threaded, each
> connection to the server creates a new thread and many various custom class
> objects are loaded per thread, some of them containing a very large amount
> of data.

This is a naive and bad approach. See below.

Quote:
> objects, is there only one copy in memory that is shared among the various
> threads that are running?

All kind of variables but thread-specific variables are shared between
threads. Thread-specific variables are accessed with thread#[] (see
http://www.rubycentral.com/book/ref_c_thread.html#Thread._ob_cb )

Quote:
> Are there other issues to consider regarding scalibility?

Consider the following real story:

Couple years back, our team had to build a web robot. It is a program
that recursively fetches web pages.

One of my (dumb and stuborn) team member insisted in using one thread
for each connection. So, if there are 700 simultaneous connections,
there are at least 700 threads. Each thread perform the following
tasks in order: get next url, resolve dns, connect, get page, store
page in dbase so that it can be parsed later on.

Such large number of threads are guaranteed to kill the computer
performance as more times are spent switching threads rather than
doing the actual work.

My solution is to use 5 threads no matter how many connections there
are. Each threads do the specific jobs: get next url, resolve dns,
connect (non-blocking), get page (using select()), store page in
dbase. This works only in UNIX, but then at that time Windows didn't
inspire much confidence for working with large number of
connections. I can't say much about Windows as I've never seen its
source code, nor ever bother to read documentations (infamous for
their inaccuracy). At least in Linux, if you have 700 simultaneous
connection, there is still only one kernel thread that move packets
from the ethernet device to the main ram. <gossip, unproven
assertion> In Windows, I was told, the Async I/O uses kernel
thread. Whether or not this is true, it is obviously an inefficient
solution to handling many connections. </gossip, /unproven assertion>

Think of threads as assembly lines. Had Ford required 700 assembly
lines to simultaneously make 700 T-models, the automobile world would
never even see a single T-model.

So, in the end, if you see that your number of threads are growing in
step with the number of connection, perhaps it is time for you to
re-evaluate the design.

YS.



Mon, 21 Mar 2005 16:09:59 GMT  
 Please help, question regarding threads
Hello Yohanes,


Quote:
>> I am working on a server-oriented application which is threaded, each
>> connection to the server creates a new thread

YS> So, in the end, if you see that your number of threads are growing in
YS> step with the number of connection, perhaps it is time for you to
YS> re-evaluate the design.

if he writes server, not client, it is better to use one thread per
connection. also, ruby threads are very light and IMHO you can't save
time by simulating thread switching in your own code

also, about thread-specific data - all blocks created when executing
new thread will have data independent from other threads

--
Best regards,



Mon, 21 Mar 2005 17:14:03 GMT  
 Please help, question regarding threads

B> data can be made local to the thread only by calling method or creating
B> closure (standard ruby ways to make local data)

 ruby has thread local variables.

Guy Decoux



Mon, 21 Mar 2005 17:53:48 GMT  
 Please help, question regarding threads

Quote:

> Hello Yohanes,


>>>I am working on a server-oriented application which is threaded, each
>>>connection to the server creates a new thread

> YS> So, in the end, if you see that your number of threads are growing in
> YS> step with the number of connection, perhaps it is time for you to
> YS> re-evaluate the design.

> if he writes server, not client, it is better to use one thread per
> connection. also, ruby threads are very light and IMHO you can't save
> time by simulating thread switching in your own code

Would you care to explain why? I can give you a great example of at
least one protocol where setting a thread per connection is a terrible
idea, XMPP (Jabber). Since the protocol expects the user to setup a
long-running socket per user, even though the traffic across this socket
is relatively low, a thread per connection would kill your scalability.

If the usage of these sockets is short-lived, and there is a limited
number of connections established, I can understand a thread per
connection, as it make design significantly easier. However, this
imposes scalability restrictions on your software at design time, and
should you decide later you need more scalability in your software,
you'll have to throw more money, either in the form of bigger hardware,
or time refactoring.

Admittedly, I don't know all the specifics around the design of ruby's
thread implementation, but I would venture a guess that a thread per
socket in any software where you need a highly scalable network server
is a bad idea. Keep in mind, however, that the thread implementation in
ruby (the C interpreter) is likely to be radically different from an
implementation in JRuby (the Java interpreter).

bs.



Tue, 22 Mar 2005 03:18:08 GMT  
 Please help, question regarding threads
Hello Ben,


Quote:
>> if he writes server, not client, it is better to use one thread per
>> connection. also, ruby threads are very light and IMHO you can't save
>> time by simulating thread switching in your own code

BS> Would you care to explain why?

because you need to work with several connections in one thread,
emulating ruby own threads. on my 1200 mhz box, ruby primitives run in
about 1 microsec, thread switching is about 20 microsec, and
create+destroy thread is about 50 microsec

BS> is a bad idea. Keep in mind, however, that the thread implementation in
BS> ruby (the C interpreter) is likely to be radically different from an
BS> implementation in JRuby (the Java interpreter).

may be or may be not. who knows :)

--
Best regards,



Tue, 22 Mar 2005 12:54:54 GMT  
 Please help, question regarding threads

Quote:

> BS> is a bad idea. Keep in mind, however, that the thread implementation in
> BS> ruby (the C interpreter) is likely to be radically different from an
> BS> implementation in JRuby (the Java interpreter).

> may be or may be not. who knows :)

I know! :)
JRuby uses Java's threads, so they are indeed radically different.

/Anders

--

_____________________________________________________
Gratis e-mail resten av livet p? www.yahoo.se/mail
Busenkelt!



Tue, 22 Mar 2005 18:25:31 GMT  
 Please help, question regarding threads
Hello Anders,


Quote:

>> BS> is a bad idea. Keep in mind, however, that the thread implementation in
>> BS> ruby (the C interpreter) is likely to be radically different from an
>> BS> implementation in JRuby (the Java interpreter).

>> may be or may be not. who knows :)

AB> I know! :)
AB> JRuby uses Java's threads, so they are indeed radically different.

jruby have compatibility problems with ruby in this area? f.e. class
variables are global?

--
Best regards,



Tue, 22 Mar 2005 19:39:19 GMT  
 Please help, question regarding threads

Quote:

> AB> I know! :)
> AB> JRuby uses Java's threads, so they are indeed radically different.

> jruby have compatibility problems with ruby in this area? f.e. class
> variables are global?

No, the language itself behaves the same.

The major difference is that Ruby's threading API is based on having
full control over thread scheduling, with methods like Thread.critical,
which stops all other threads. When you use an external implemenation of
threads, like Java's threads or POSIX threads or whatever, you don't
have that level of control.
There are many ways to get around this, so it will be interesting in the
future to watch how Rite, Cardinal and other Ruby implementations will
approach this.

/Anders

--

_____________________________________________________
Gratis e-mail resten av livet p? www.yahoo.se/mail
Busenkelt!



Tue, 22 Mar 2005 20:39:32 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Question regarding threads and perhaps YAML

2. Question regarding module variables and thread safety

3. help regarding acc_set_value() please.

4. Gawk 3.1.1 - Question regarding a variable in a print statement and help with code

5. HELP !! Some questions regarding CMU LISP

6. please, please, please, please, help

7. will someone please, please, please, please HELP me?!!

8. Please: Help wanted with threads

9. Please help: Aonix ObjectAda on NT & Threads

10. Help with Threads and httplib please

11. Please help: Python1.4 w/ threads, Solaris

12. Please: Help wanted with threads

 

 
Powered by phpBB® Forum Software