On Wed, Jan 09, 2002 at 09:16:33AM -0500, Stephen Adkins wrote: > At 06:18 PM 1/7/2002 +0100, [EMAIL PROTECTED] wrote: > >On Mon, Jan 07, 2002 at 09:13:23PM +0800, Gunther Birznieks wrote: > >> Yes, but what does this have to do with 5.6.1? Are you saying you can't > >> write thread-safe code that is also backwards compatible with 5.5? > > > >of course not. but if we need threads anyway (do we?) or in most of the > >cases, does there need to be support for 5.5 ? > > > > Hi, > > I personally do not plan to rely on threads or thread-safety whatsoever. > Building Enterprise Software does not depend on it. > And the portability issues of multi-threading are numerous. That depends on the problems that the software has to deal with, not wether it's an enterprise class problem or from another domain. There are a lot of solutions that use concurrency.
> > My experience with threads is that the performance overhead of using > general-purpose thread-safe libraries (RogueWave in C++) with all of their > internal locking is so great that it is rarely overcome by the supposed > performance benefits of threading. That might be correct for this specific library. But it really depends on the design again. Non-parallel algorithms won't benefit from threading, parallel will. The performance of thread-safe algorithms depends on the level of parallelization of the algorithm (how distinct they are from each other in terms of resources). This again depends on design and implementation aspects, like lock granularity. If the p5ee libs do know more about data semantics than the underlying libraries (which helps in several other cases as well) they will be able to minimize critical section wait times. For example you could have a list of numbers and two actions, one adding all numbers > 100 and one dividing all numbers < 100 by two. the p5ee libs could run the two actions concurrently as it knows that the affected sets are different, underlying libraries could not as they only know that both actions work on the same list. > > I am designing P5EEx::Blue to operate in a multi-process/IPC environment. > > I will keep multi-threading in mind in the design, mainly to support > multi-threaded mod_perl 2.0 on the Windows platform. Multi-process designs are only useful if the amount of shared data is low. That is just sometimes the case. If you have to pipe a lot of shared data through some protocol and update values in all adress spaces, this won't be performant at all. How often do you hear people that keep away from Perl because it has no threading support? How many enterprises have multi-processor machines? What about performance on their machines (with lots of shared data...) ? p5ee shouldn't ignore all these things. Thread-safety is not easy, achieving it without big performance penalties is even harder. There might not be a complete solution yet, but we should at least try! Torvald
