Hello,
I would like to suggest to read the following articles
at http://www.cs.wustl.edu/~schmidt/report-doc.html
(he has there a ps doc for each article)
--------------------------------
13.Comparing Alternative Programming Techniques for Multi-threaded Servers --
the Thread-per-Session Concurrency Model, SIGS, Vol 8. No 7. July 1996.
This column examines and evaluates three techniques for developing
multi-threaded servers using the ``thread-per-session'' concurrency model.
These techniques include using the socket network programming interface,
using C++ wrappers for sockets, and using multi-threaded Orbix.
14.Comparing Alternative Programming Techniques for Multi-threaded Servers --
the Thread-Pool Concurrency Model, SIGS, Vol 8. No 4. April 1996.
This column examines and evaluates three techniques for developing
multi-threaded servers using the ``thread-pool'' concurrency model. These
techniques include using the socket network programming interface, using C++
wrappers for sockets, and using multi-threaded Orbix.
15.Comparing Alternative Programming Techniques for Multi-threaded Servers --
the Thread-per-Request Concurrency Model, SIGS, Vol 8. No 2. February 1996.
This column examines and evaluates four techniques for developing
multi-threaded servers using the ``thread-per-request'' concurrency model.
These techniques include using the socket network programming interface,
using C++ wrappers for sockets, and using two multi-threaded versions of
CORBA (Orbix and HP ORB Plus).
------------------------------------------------------------------------
I hope those papers will help you to decide what thread model to use for your
particular application. Most of the models, I think, are implemented in the
ACE C++ toolkit, but I am not 100% sure (but for sure you do not need to
be concerned with any CORBA's if you just want to use the described thread
models)
I found that for applications that use any OS or other resources that are
expensive to tear down (like database connection, sockets, etc) thread pool
models work the best, because there a programmer has control over what
resources to can be bound to the items in the pool.
Regards,
Vladislav
On Mon, 24 Apr 2000, A G F Keahan wrote:
> Jason and Richard,
>
> thank you very much for your explanations of libc_r and
> LinuxThreads. Due to the significant processing time of each request
> (typically between 50-800ms, averaging 100ms), I doubt that FreeBSD's
> threads would perform any worse than if I forked a separate process for
> each connection (memory usage would go sky high), or even if I had a
> single process and called poll() myself to check each descriptor for
> being readable/writable. What worries me though is that by design
> client connections are kept alive (although the server is allowed to
> disconnect a client after a period of inactivity), hence after a while
> there will be a lot of idle descriptors, and continuously polling them
> might slow down the processing of the active ones. I have to
> experiment to find out what's best -- the goal is to do better than NT
> (which surprisingly does quite a good job when it comes to processing
> lots of threads). Solaris's threads are pretty darn good too, but I
> dislike all things SystemV-ish, and Solaris/x86 isn't all that hot
> either (compared with the version for the UltraSPARC).
>
>
>
> > On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote:
> > > On Mon, Apr 24, 2000 at 05:17:10AM +0300, A G F Keahan wrote:
> > > > I am currently porting a multithreaded TCP server from NT (yech!) to
> > > > UNIX using pthreads. The server has a fairly straightforward design --
> > > > it opens a thread for each connection, and each thread spends most of
> > > > its life blocked in a call to read() from a socket. As soon as it
> > > > receives enough of a request, it does quite a bit of processing and
> > > > sends something back to the client.
> > >
> > > This design isn't ideal on any OS, but the fact that you do significant
> > > processing every time a request arrives on a socket probably hides most of
> > > the inefficiency due to thread switching and lack of cache locality due to
> > > many thread stacks.
>
>
> Can you suggest a better design for this type of server application
> under FreeBSD? Perhaps a combination of forking (or pre-forking) and
> threads?
>
>
>
> > > > How would FreeBSD 4.0 perform in such a scenario? We are talking
> > > > hundreds, maybe thousands of threads, a lot of them doing blocking reads
> > > > and writes. Is the standard pthreads library adequate for the task, or
> > > > would "Linuxthreads" be a better choice? What is the main difference
> > > > between the standard FreeBSD pthreads and "Linuxthreads" -- it seems
> > > > both are implemented using a version of clone().
> > >
> > > FreeBSD's threads should perform adequately given the design of your program
> > > and the hardware you listed. Actually trying it on the various operating
> > > systems would be a good exercise, but I have found that FreeBSD's threads
> > > perform at least as well as Solaris's for such an application.
> >
> > Interesting. I would have thought Solaris would be much superior.
>
>
> I would have thought so too... we'll see.
>
> Thanks again
>
> Alex Keahan
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
--
..
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
