I'm not an educator. There is a certain level of inability to see the obvious that I am neither qualified nor inclined to address.
You haven't proven the "blindingly obvious reasons". And I until you do - they're no more than your personal religious beliefs that there's something fundamentally wrong with using worker processes. No need to make insults about my inability to understand figments of your imagination.
The quoted excerpt is only applicable to a single-process single-thread environment - i.e. one that does not allow the programmer to benefit from SMP. It is thus irrelevant.
False. One or more processes, and as many threads per process as your Unix OS resources will allow. With ST, intra-process synchronization is done for you. Read the darn document!
You can scale your ST application for SMP by running as many processes as you have CPUs. It's right there in the docs. I agree that how this scales compared to pthreads needs to be tested, and on different hardware (SMP, NUMA, etc.). Though authors _claim_ it scales better than pthreads.
So forcing programmers to use explicit IPC and semaphores is your idea of freeing them from the burden of classical multi-process models? Ummm, no. That is the burden of classical multi-process models. That's what the framework should be helping the programmer to avoid. The reason for the error becomes clear if we go back a sentence or two, though:
Wrong again. Nodoby forces you to do anything. Unless you're again, dreaming. As per the documentation, inter-process synchronization is only required if you need to share objects between the processes, which is a rare case. I would never do something like this if I built an FTP or a messaging server. And even if it needs to be done due to a server design, it is still very easy to do. Much easier than locking things between pthreads and debugging them. What's your big deal? They also explain just how easy it is to do. ST is not a pure threads library, as I said before - it's a hybrid. It in fact, emulates a thread/connection paradigm with a state machine using poll or select. The synchronization is done for you through event handling. And what exactly burden of "classical multi-process models" are you suddenly babbling about now? Are you going to give us some other "blindingly obvious reasons" not to use this model? It certainly has its place too, you know. I may as well view any and all threads as a bad paradigm using your methodology -- just because I make myself believe so!
I am starting to think you have religious preconceptions to believe there's something fundamentally wrong with a library like ST, or multi-process models. I believe there's a best tool for the job. To each his own, I guess.
I'd like to end this thread here, as I am tired to respond to your baseless and ignorant claims about ST. Don't like it, bitch about it all you want - but at least make sense.
Also Eddie, is an HA solution, not load balancing only. HA doesn't need to be a kernel feature. Eddie may even be better than what Linux kernel offers, or it may not. HA software does not need to be in-kernel.
Worker processes are even worse than worker threads, again for blindingly obvious reasons.
You won't convince me until you prove this is true for any kind of library, any kind of server, on any kind of hardware, such as you claim:). Somehow I cannot see such blindingly obvious reasons.
Running a process or thread per CPU is no trick at all. You can do it with a traditional multi-process design, you can do it with a state-machine design, you can do it with a staged design. The first real trick is to have the infrastructure rather than the programmer ensure that you are in fact running one process per CPU...which the ST docs explicitly state it doesn't do for you.
Who said it's a trick?
The second trick is to remove from the programmer some of the synchronization and concurrency burden associated with handling parallelism the old-fashioned way...which ST also does not do.
This is simply wrong, as I stated before, ST takes away all burden associated with programming servers using pthreads. Quoting documentation:
Due to the event-driven nature of the library scheduler, the thread context switch (process state change) can only happen in a well-known set of library functions. This set includes functions in which a thread may "block": I/O functions (st_read(), st_write(), etc.), sleep functions (st_sleep(), etc.), and thread synchronization functions (st_thread_join(), st_cond_wait(), etc.). As a result, process-specific global data need not to be protected by locks since a thread cannot be rescheduled while in a critical section (and only one thread at a time can access the same memory location). By the same token, non thread-safe functions (in a traditional sense) can be safely used with the State Threads. The library's mutex facilities are practically useless for a correctly written application (no blocking functions in critical section) and are provided mostly for completeness. This absence of locking greatly simplifies an application design and provides a foundation for scalability.
For the rare case where you actually need to share data between processes:
Ideally all user sessions are completely independent, so there is no need for inter-process communication. It is always better to have several separate smaller process-specific resources (e.g., data caches) than to have one large resource shared (and modified) by all processes. Sometimes, however, there is a need to share a common resource among different processes. In that case, standard UNIX IPC facilities can be used. In addition to that, there is a way to synchronize different processes so that only the thread accessing the shared resource will be suspended (but not the entire process) if that resource is unavailable. In the following code fragment a pipe is used as a counting semaphore for inter-process synchronization:
The person to whom I am responding doesn't mention any other thread libraries available. Just because he/she hasn't profiled other libraries doesn't mean *BSD is bad at threading.
I may have flamed that AC, but stating *BSD doesn't support any clustering at all is absurd. High availability clustering is available for *BSD through "Eddie" and other such software.
Because I have written servers for a variety of applications over the last decade-plus, and in every case doing disk I/O through worker threads was a major lose. Yes, I have done benchmarks. There's even one set that's on my already-cited website; I believe it's under the "tech_design" category in the archives, but the reasons why that approach sucks are so blindingly obvious that I can't be bothered verifying the category.
It's worker processes, not threads. I don't see a direct relation between your experience and performance of an ST application. Until you show me the actual measurements you made which prove a few worker processes will significantly bog down an ST server, I won't belive you either:). If you want to discuss these issues for the fun of it, join ST mailing list. It's very low-volume.
I'm going to try to stay on topic here, and not bash state threads unnecessarily. The question before us is this: do state threads take full advantage of SMP, without degenerating into something indistinguishable from the traditional multi-process model? Do you have any evidence yet to support that claim?
And what's wrong with simplicity? If running a process per CPU provides SMP scalability why do we need anything else? I don't have numbers to prove it, no. I do know that the second process will be handled by the second CPU on a two CPU machine, however. I do wish the ST folks would show us some actual documented SMP benchmarks though.
I don't believe everything, but the bottom line is: pthreads are harder to use for building Internet servers. At least with ST, synchronization issues appear only when you need to share data between those processes. It's not the common case for most servers. Most sessions are completely independent of each other, such as in FTP servers for instance.
With pthreads OTOH, you always need to be concerned with synchronization - major PITA. Writing with pthreads and debugging isn't fun at all. Look at all the pthread-related bugs out there with OpenLDAP for instance.
How do you know performance will suck in the worker case? Did you run benchmarks? Do you have measurements to support this claim? In any case using this library should be inherently better for performance than starting a thread per connection, and context switching yourself to death. Or fork/exec a process per connection, and do the same. But as always, profile, don't speculate.
http://state-threads.sourceforge.net/docs/st.htm l
which explains unless you have worker processes for the disk I/O, in their threads library implementation, the process and all its threads will be blocked by it (the I/O). It scales on SMP because it's a hybrid library. Two CPUs? The library will start two processes, and a number of threads. Four CPUs? Start four processes, etc.
It's a multi-process multi-thread library. The apache MPM module they wrote (Apache Accelerating Projec) scales better than Apache's own pthread-based modules. Several times better. Read their pages.
Why is it that people automatically assume there's only one thread library, the pthread library which ships with the system and ties-in to the kernel. There's more than one way to do threading. There's more than one pthread implementation available, and more non-pthread libraries which are specifically designed for writing server applications, easier to use, debug, and scale better than pthreads. pthreads are not suitable for writing Internet servers. They're generic threads.
See http://annexia.org/freeware/pthrlib/ or http://state-threads.sourceforge.net
for instance. State threads scales better than pthreads for Internet servers, doesn't need reentrant libraries, doesn't need mutexes and locks, and therefore is a better solution. And yes, it does scale on SMP.
You don't know what you're talking about. There's more than one thread library, and not all of them are pthread implementations. pthreads are generic threads not designed for Internet servers, and not suitable for them. See
http://state-threads.sourceforge.net
http://www.gnu.org/software/pth/
state threads scales better than Apache's pthread MPM module, several times better. And it's completely user-land. Profile, don't speculate!
For which operating systems and which thread libraries? Pthreads are unsuitable for Internet servers since they're generic, preemtable, concurrent threads. There are plenty of other threading libraries specifically designed for Internet servers, and do not even touch the kernel space.
State threads MPM is several times faster than default Apache 2.0 on Linux. Quite possibly even faster on larger OSes.
I agree with the notion best tool for the job. However upgrades are very easy with *BSD. Make world, modify configs, reboot. None of that package stuff.
Utter garbage. There's nothing preventing BSD from clustering. MPI software runs on *BSD. Even MOSIX was originally built for FreeBSD. Get your facts straight before spewing disinfo into slashdot. Idiot.
Debian doesn't build the world for you. I find cvssing down the build tree far more easier that apt. I've used Debian for a couple of years, and loved it, until I found out just how easier it is with *BSD. Cheers.
This is utter garbage. *BSDs are much easier to configure and manage. Which is exactly why we're switching from Linux to FreeBSD. I am sick of hard to do upgrades for the OS and its components. With *BSDs it's cvsup, make buildworld, installworld, modify config files, and done.
Slashdot Mirror
I'm not an educator. There is a certain level of inability to see the obvious that I am neither qualified nor inclined to address.
You haven't proven the "blindingly obvious reasons". And I until you do - they're no more than your personal religious beliefs that there's something fundamentally wrong with using worker processes. No need to make insults about my inability to understand figments of your imagination.
The quoted excerpt is only applicable to a single-process single-thread environment - i.e. one that does not allow the programmer to benefit from SMP. It is thus irrelevant.
False. One or more processes, and as many threads per process as your Unix OS resources will allow. With ST, intra-process synchronization is done for you. Read the darn document!
You can scale your ST application for SMP by running as many processes as you have CPUs. It's right there in the docs. I agree that how this scales compared to pthreads needs to be tested, and on different hardware (SMP, NUMA, etc.). Though authors _claim_ it scales better than pthreads.
So forcing programmers to use explicit IPC and semaphores is your idea of freeing them from the burden of classical multi-process models? Ummm, no. That is the burden of classical multi-process models. That's what the framework should be helping the programmer to avoid. The reason for the error becomes clear if we go back a sentence or two, though:
Wrong again. Nodoby forces you to do anything. Unless you're again, dreaming. As per the documentation, inter-process synchronization is only required if you need to share objects between the processes, which is a rare case. I would never do something like this if I built an FTP or a messaging server. And even if it needs to be done due to a server design, it is still very easy to do. Much easier than locking things between pthreads and debugging them. What's your big deal? They also explain just how easy it is to do. ST is not a pure threads library, as I said before - it's a hybrid. It in fact, emulates a thread/connection paradigm with a state machine using poll or select. The synchronization is done for you through event handling.
And what exactly burden of "classical multi-process models" are you suddenly babbling about now? Are you going to give us some other "blindingly obvious reasons" not to use this model? It certainly has its place too, you know. I may as well view any and all threads as a bad paradigm using your methodology -- just because I make myself believe so!
I am starting to think you have religious preconceptions to believe there's something fundamentally wrong with a library like ST, or multi-process models. I believe there's a best tool for the job. To each his own, I guess.
I'd like to end this thread here, as I am tired to respond to your baseless and ignorant claims about ST. Don't like it, bitch about it all you want - but at least make sense.
But again, the original poster claimed *BSD cannot do _ANY_ clustering.
Also Eddie, is an HA solution, not load balancing only. HA doesn't need to be a kernel feature. Eddie may even be better than what Linux kernel offers, or it may not. HA software does not need to be in-kernel.
I never said it doesn't. Tahnks for wasting bandwidth.
That's besides the point. The original poster claimed =there is no clustering AVAILABLE FOR *BSD.=
Worker processes are even worse than worker threads, again for blindingly obvious reasons.
:). Somehow I cannot see such blindingly obvious reasons.
You won't convince me until you prove this is true for any kind of library, any kind of server, on any kind of hardware, such as you claim
Running a process or thread per CPU is no trick at all. You can do it with a traditional multi-process design, you can do it with a state-machine design, you can do it with a staged design. The first real trick is to have the infrastructure rather than the programmer ensure that you are in fact running one process per CPU...which the ST docs explicitly state it doesn't do for you.
Who said it's a trick?
The second trick is to remove from the programmer some of the synchronization and concurrency burden associated with handling parallelism the old-fashioned way...which ST also does not do.
This is simply wrong, as I stated before, ST takes away all burden associated with programming servers using pthreads. Quoting documentation:
Due to the event-driven nature of the library scheduler, the thread context switch (process state change) can only happen in a well-known set of library functions. This set includes functions in which a thread may "block": I/O functions (st_read(), st_write(), etc.), sleep functions (st_sleep(), etc.), and thread synchronization functions (st_thread_join(), st_cond_wait(), etc.). As a result, process-specific global data need not to be protected by locks since a thread cannot be rescheduled while in a critical section (and only one thread at a time can access the same memory location). By the same token, non thread-safe functions (in a traditional sense) can be safely used with the State Threads. The library's mutex facilities are practically useless for a correctly written application (no blocking functions in critical section) and are provided mostly for completeness. This absence of locking greatly simplifies an application design and provides a foundation for scalability.
For the rare case where you actually need to share data between processes:
Ideally all user sessions are completely independent, so there is no need for inter-process communication. It is always better to have several separate smaller process-specific resources (e.g., data caches) than to have one large resource shared (and modified) by all processes. Sometimes, however, there is a need to share a common resource among different processes. In that case, standard UNIX IPC facilities can be used. In addition to that, there is a way to synchronize different processes so that only the thread accessing the shared resource will be suspended (but not the entire process) if that resource is unavailable. In the following code fragment a pipe is used as a counting semaphore for inter-process synchronization:
Maybe, but it also ran on FreeBSD.
The person to whom I am responding doesn't mention any other thread libraries available. Just because he/she hasn't profiled other libraries doesn't mean *BSD is bad at threading.
I may have flamed that AC, but stating *BSD doesn't support any clustering at all is absurd. High availability clustering is available for *BSD through "Eddie" and other such software.
http://eddie.sourceforge.net/what.html
Because I have written servers for a variety of applications over the last decade-plus, and in every case doing disk I/O through worker threads was a major lose. Yes, I have done benchmarks. There's even one set that's on my already-cited website; I believe it's under the "tech_design" category in the archives, but the reasons why that approach sucks are so blindingly obvious that I can't be bothered verifying the category.
:). If you want to discuss these issues for the fun of it, join ST mailing list. It's very low-volume.
It's worker processes, not threads. I don't see a direct relation between your experience and performance of an ST application. Until you show me the actual measurements you made which prove a few worker processes will significantly bog down an ST server, I won't belive you either
I'm going to try to stay on topic here, and not bash state threads unnecessarily. The question before us is this: do state threads take full advantage of SMP, without degenerating into something indistinguishable from the traditional multi-process model? Do you have any evidence yet to support that claim?
And what's wrong with simplicity? If running a process per CPU provides SMP scalability why do we need anything else? I don't have numbers to prove it, no. I do know that the second process will be handled by the second CPU on a two CPU machine, however. I do wish the ST folks would show us some actual documented SMP benchmarks though.
I don't believe everything, but the bottom line is: pthreads are harder to use for building Internet servers. At least with ST, synchronization issues appear only when you need to share data between those processes. It's not the common case for most servers. Most sessions are completely independent of each other, such as in FTP servers for instance.
With pthreads OTOH, you always need to be concerned with synchronization - major PITA. Writing with pthreads and debugging isn't fun at all. Look at all the pthread-related bugs out there with OpenLDAP for instance.
How do you know performance will suck in the worker case? Did you run benchmarks? Do you have measurements to support this claim? In any case using this library should be inherently better for performance than starting a thread per connection, and context switching yourself to death. Or fork/exec a process per connection, and do the same. But as always, profile, don't speculate.
You obviously didn't read this paper:
m l
http://state-threads.sourceforge.net/docs/st.ht
which explains unless you have worker processes for the disk I/O, in their threads library implementation, the process and all its threads will be blocked by it (the I/O). It scales on SMP because it's a hybrid library. Two CPUs? The library will start two processes, and a number of threads. Four CPUs? Start four processes, etc.
It's a multi-process multi-thread library. The apache MPM module they wrote (Apache Accelerating Projec) scales better than Apache's own pthread-based modules. Several times better. Read their pages.
Sure, if we all derange ourselves into automatically believing threads are always faster than processes. Measure, don't just imagine.
Why is it that people automatically assume there's only one thread library, the pthread library which ships with the system and ties-in to the kernel. There's more than one way to do threading. There's more than one pthread implementation available, and more non-pthread libraries which are specifically designed for writing server applications, easier to use, debug, and scale better than pthreads. pthreads are not suitable for writing Internet servers. They're generic threads.
See http://annexia.org/freeware/pthrlib/
or
http://state-threads.sourceforge.net
for instance. State threads scales better than pthreads for Internet servers, doesn't need reentrant libraries, doesn't need mutexes and locks, and therefore is a better solution. And yes, it does scale on SMP.
You don't know what you're talking about. There's more than one thread library, and not all of them are pthread implementations. pthreads are generic threads not designed for Internet servers, and not suitable for them. See
http://state-threads.sourceforge.net
http://www.gnu.org/software/pth/
state threads scales better than Apache's pthread MPM module, several times better. And it's completely user-land. Profile, don't speculate!
The world doesn't run on Linux, idiot.
For which operating systems and which thread libraries? Pthreads are unsuitable for Internet servers since they're generic, preemtable, concurrent threads. There are plenty of other threading libraries specifically designed for Internet servers, and do not even touch the kernel space.
State threads MPM is several times faster than default Apache 2.0 on Linux. Quite possibly even faster on larger OSes.
With Linux distros upgrades are packaged, very time consuming, and error prone. CVS does it for me orders of magnitude faster. Try it someday.
I agree with the notion best tool for the job. However upgrades are very easy with *BSD. Make world, modify configs, reboot. None of that package stuff.
Make world.
Utter garbage. There's nothing preventing BSD from clustering. MPI software runs on *BSD. Even MOSIX was originally built for FreeBSD. Get your facts straight before spewing disinfo into slashdot. Idiot.
Debian doesn't build the world for you. I find cvssing down the build tree far more easier that apt. I've used Debian for a couple of years, and loved it, until I found out just how easier it is with *BSD. Cheers.
What is the algorithm to upgrade a Linux distro to a new version?
Here's the algorithm for FreeBSD: cvsup, make world, edit configs, reboot. I choose *BSD for easier administration, and Linux where I can't use a BSD.
This is utter garbage. *BSDs are much easier to configure and manage. Which is exactly why we're switching from Linux to FreeBSD. I am sick of hard to do upgrades for the OS and its components. With *BSDs it's cvsup, make buildworld, installworld, modify config files, and done.
And why not one of the BSDs? They're so much easier to adminisiter, which is exactly why we're switching to *BSD here.