In the context of NIO based WebServer's (Grizzly to be specific), is the terminology "Acceptor Thread" and "Selector Thread" interchangeable?
As per this doc https://docs.oracle.com/cd/E19900-01/819-4742/gcsvs/index.html
Acceptor threads are threads used to serve OP_ACCEPT (socket.accept())
Selector Threads are threads used to handing OP_READ operations.
So No , they are not interchangeable
Related
An app makes 3 simultaneous HTTP requests to web server. using asynchronus technique, how many worker threads will be tied up waiting for the data
It wouldn't tied up, Because when you’re doing asynchronous work, you’re not always using a thread.
For example, if you made an async web service request, your client will not be using any threads between the “send” and “receive”.
You unwind after the “send”, and the “receive” occurs on an I/O completion port, at which time your callback is invoked and you will then be using a thread again. (Note that for this scenario your callback is executed on an i/o thread ASP.NET only uses worker threads, and only includes worker threads when it counts the threads in-use.)
Please see the warning below taken from the StreamWriter class specification:
"Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe."
I understand that a W3WC process contains two thread pools i.e. worker threads and I/O threads. A worker thread could contain many threads of its own (if the application creates its own System.Thread instances).
Does the warning only relate to System.Threads or does it relate to worker threads and I/O threads as well I.e. as the instance variables of the StreamWriter class are not thread safe then does this mean that there would be problems if multiple worker threads access it, e.g. if two users on two different web clients attempt to write to the log file at the same time, then could one lock out the other?
If a class isn't threadsafe, then you can't take an instance of that class and use that instance from more than one thread. It doesn't matter whether they're System.Threading.Thread or ThreadPool or Task or worker threads within IIS. They're all threads -- they're all preemptive multitasking while the object is in a state where it doesn't expect to be preempted.
That doesn't matter in the scenario you describe, though. Suppose two Web clients try to connect to the server at the same time, and your request handler tries to log to a file, meaning you've got two threads potentially trying to write to that file simultaneously. But that's not a thread-safety issue, because you wouldn't be using the same StreamWriter instance in both threads. (At least, I hope not -- if you have a static StreamWriter instance, how would you ever know when to flush it and close the file? Sharing the same writer across threads wouldn't make any sense.)
Instead, each thread should create its own StreamWriter, write to it, and then close it. Yes, there are still concurrency issues -- if the first thread hasn't closed the file yet when the second thread tries to open the file, then the second thread would get a file-sharing exception, and you would need to catch that exception and retry -- but that's a file-locking issue, not a thread-safety issue.
I've read through this page on some improvements that can be made for an ASP.NET application. However, I'm still not sure how maxWorkerThreads, maxIoThreads, and minFreeThreads functions together.
From what I understand, the minFreeThreads setting specifies the minimum number of worker threads available for callbacks, etc.... If I have a page that makes an asynchronous call to a web service, does this call use one of these free threads or does it use an IO thread? When does an IO thread get used and when are these free threads used?
I believe that I/O threads are consumed (and released) in regards to I/O operations (System.IO namespace). I'm guessing that this would typically disk reads/writes. This resource is a bit old, but I think most of the concepts have remained the same.
http://www.guidanceshare.com/wiki/ASP.NET_2.0_Performance_Guidelines_-_Threading
we have a scenario where in whil serving one asp.net request from iis from our code we have created a child thread from thread pool to servve some background task.the idea was to finsih the main thread wihich is processing the request without depending on our child thread task. But our doubt is while processing a request in asp.net will workerprocess wiat untill the thread finishes its task ?
No, if you've created a separate thread and don't have any code to wait on it, the request will certainly complete.
What I don't know is whether a worker process can be recycled while there are non-ASP.NET thread pool threads executing. I strongly suspect it can - so be aware that your child task could be terminated at any point. If this is a problem, you may wish to create a non-threadpool foreground thread.
No, the background thread will not wait for the main thread to finish, it will start immediately. If you use the Thread pool your task may have to wait for a thread to be available, but that is all.
You should however be aware that this may not be a good solution, for the application domain your asp.net site is running in may be recycled while your background thread is running. This will kill the background thread leaving the task incomplete. If it is possible, you should separate the background task into a service application that runs in a separate process. This will ensure that the task isn't killed while running.
Looking at the processmodel element in the Web.Config there are two attributes.
maxWorkerThreads="25"
maxIoThreads="25"
What is the difference between worker threads and I/O threads?
Fundamentally not a lot, it's all about how ASP.NET and IIS allocate I/O wait objects and manage the contention and latency of communicating over the network and transferring data.
I/O threads are set aside as such because they will be doing I/O (as the name implies) and may have to wait for "long" periods of time (hundreds of milliseconds). They also can be optimized and used differently to take advantage of I/O completion port functionality in the Windows kernel. A single I/O thread may be managing multiple completion ports to maintain throughput.
Windows has a lot of capabilities for dealing with I/O blocking whereas ASP.NET/.NET has a plain concept of "Thread". ASP.NET can optimize for I/O by using more of the unmanaged threading capabilities in the OS. You wouldn't want to do this all the time for every thread as you lose a lot of capabilities that .NET gives you which is why there is a distinction between how the threads are intended to be used.
Worker threads are threads upon which regular "work" or just plain code/processing happens. Worker threads are unlikely to block a lot or wait on anything and will be short running and therefore require more aggressive scheduling to maximize processing power and throughput.
[Edit]: I also found this link which is particularly relevant to this question:
http://blogs.msdn.com/ericeil/archive/2008/06/20/windows-i-o-threads-vs-managed-i-o-threads.aspx
Just to add on to chadmyers...
Seems like I/O Threads was the old way ASP.NET serviced requests,
"Requests in IIS 5.0 are typically
serviced over I/O threads, or threads
performing asynchronous I/O because
requests are dispatched to the worker
process using asynchronous writes to a
named pipe."
with IIS6.0 this has changed.
"Thus all requests are now serviced by
worker threads drawn from the CLR
thread pool and never on I/O threads."
Source: http://msdn.microsoft.com/hi-in/magazine/cc164128(en-us).aspx