how expensive contextswitch blocked thread.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

how expensive contextswitch blocked thread.

alarmnummer
I have a question about contextswitching and blocked threads. My guess is that the operating system doesn`t need to schedule threads that are blocked untill they are unblocked. The consequence is that it shouldn`t be to expensive having a lot of blocking threads because the operating system doesn`t have to restore state to threads that can`t do anything. Is this correct? Having 10 running threads would just be as fast as 10 running threads and 1000 blocked threads.

The reason I`m asking this is because I would like to understand why non blocking io is preferred above blocking io. Non blocking io is considered better scalable because it doesn`t have so many blocking threads, but I don`t understand the reason why (if the operating system doesn`t schedule blocked threads).


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: how expensive contextswitch blocked thread.

Greg Gagne
Yes, the operating system only schedules threads that are available to run, not those that cannot run because they are blocking (i.e. for IO reasons, to acquire a lock, etc.) However, the OS must still maintain the necessary in-memory data structures for each thread in the system, regardless whether they are running, eligible to run, or are blocked.. The primary argument against having a substantial number of blocking threads is that a thread is used for maintaining state and a thread is not necessarily a small data structure for storing such state.

This leads to the non-blocking IO alternative whereby a thread (or perhaps a small number of threads) can multiplex a number of (potentially blocking) channels. The idea is that blocking state does not have to be stored in such a heavy-weight data structure as a thread.

I recall seeing a couple of presentations @ Java One a few years back (2003) about designing scalable servers. Matt Welsh also has done alot of work in this area, notably SEDA

http://www.eecs.harvard.edu/~mdw/proj/seda/

I also believe Doug Lea has done some work in this area as well.....

Lastly, there are some that argue event-oriented IO is "unnatural" and that a threading model leads to a more natural approach (from a programmers perspective.)

>From my experience, unless you are talking hundreds - or thousands - of connections, a thread-per-message approach (where a thread is used to maintain the state of each connection) is sufficient. Of course, engineering answers can best be summed up as "it depends" :-)

If you are unaware of how to use the java.nio package, I gave a workshop at SIGCSE related to this topic:

http://people.westminstercollege.edu/faculty/ggagne/sigcse2003/

This was for educators who had little experience with network programming - or Java for that matter.

Best -

//greg

>>> Peter Veentjer <[hidden email]> 12/26/05 2:20 AM >>>
I have a question about contextswitching and blocked threads. My guess is
that the operating system doesn`t need to schedule threads that are blocked
untill they are unblocked. The consequence is that it shouldn`t be to
expensive having a lot of blocking threads because the operating system
doesn`t have to restore state to threads that can`t do anything. Is this
correct? Having 10 running threads would just be as fast as 10 running
threads and 1000 blocked threads.

The reason I`m asking this is because I would like to understand why non
blocking io is preferred above blocking io. Non blocking io is considered
better scalable because it doesn`t have so many blocking threads, but I
don`t understand the reason why (if the operating system doesn`t schedule
blocked threads).


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: how expensive contextswitch blocked thread.

Brian Goetz
In reply to this post by alarmnummer
> I have a question about contextswitching and blocked threads. My guess
> is that the operating system doesn`t need to schedule threads that are
> blocked untill they are unblocked. The consequence is that it shouldn`t
> be to expensive having a lot of blocking threads because the operating
> system doesn`t have to restore state to threads that can`t do anything.
> Is this correct? Having 10 running threads would just be as fast as 10
> running threads and 1000 blocked threads.

Expensive can be interpreted in multiple currencies.  In terms of CPU
cycles consumed, you are correct that a larger number of blocked threads
will not consume proportionally more CPU cycles.  However, they will
consume more memory.  Within reason this is fine, but at some point (1K,
10K, 100K threads) you are likely to run out of something -- memory, OS
capacity, limitations of scheduling data structures.

> The reason I`m asking this is because I would like to understand why non
> blocking io is preferred above blocking io. Non blocking io is
> considered better scalable because it doesn`t have so many blocking
> threads, but I don`t understand the reason why (if the operating system
> doesn`t schedule blocked threads).

I think nonblocking I/O is preferred sometimes in some situations by
some people.  The exact calculus is much more complicated.  Older OSes
had limits of a few hundred threads; if you wanted to server more
clients than this, nonblocking I/O was essential.  It also depends on
the cost of context switches.  Nonblocking I/O generates fewer context
switches.  OTOH, nonblocking I/O is _much_ more complicated, and Java's
facility for it (nio) is NOT easy to use.

My advice is to stick with thread-per-message until the scale of your
application makes it clear that TPM will not work, because it is SO much
easier.  TPM can work for a surprisingly broad range of applications on
modern OS kernels + JVMs.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest