Date: Thu, 06 Sep 2001 12:29:02 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Ullasan_Kottummal@kindlebanksys.com, freebsd-hackers@FreeBSD.org Subject: Re: Posix Threading Message-ID: <3B97CE7E.ED6A3D0F@mindspring.com> References: <XFMail.010905151503.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > >> If the intent is to have "a pool of idle threads", ready to > >> go when you get request traffic, and get around the latency, > >> well, you'd do a lot better in the latency department if you > >> went to a finite state automaton, instead of messing with > >> threads. But if you insist, the best you are going to be > >> able to get is use of a mutex, since a condition variable will > >> result in a "thundering herd" problem. You will still have to > >> eat the latency for the mutex trigger to the thread you give > >> the work to, however (this is how I designed the work-to-do > >> dispatcher in the Pathworks for VMS (NetWare) product for DEC > >> and Novell). > > Most of what you say is ok, but this is wrong. condition variables > do not mandate using a wakeup all strategy. There is such a thing > as 'signal' instead of 'broadcast', which only wakes up one thread. My concern over recommending this would be that it is very implementation dependent as to which thread gets woken up. In Linux, it could result in a full context switch for it to be implemented by the threads system. Also I remembered something about a problem with the implementation from Draft 2, and as I said previously, I had no idea of the compliance level (this is from an experience with adapting the threads in the Standard Template Library, as distributed by the Moscow Supercomputing Center, to so correct "static" mutex initialization). In FreeBSD, you're certainly right, though it will maybe end up having the full context switch overhead (or even CPU selection overhead) once kernel threading via KSE is the norm (but in FreeBSD's implementation, you might be able to argue the same thing about mutex based triggers, if implemented such that the context is not passed off instead -- except that he wanted initial hibernation, and I don't think you could guarantee that with a mutex). FWIW, my implementation in VMS was based on DEC's MTS, which was a BLISS-based call conversion threading package, which I had to extend to have timers, and also had to add all the necessary synchorinization primitives. The basic implementation was made using ASTs with SYS$WAITEFLOR -- wait-event-flag-OR -- very similar to condition variables. The new condition variable primitive wasn't enough to give a guarantee the necessary semantics for the application (a port of Mentat Streams to VMS, in support of the SPX and IPX stacks used by NetWare), and I had to build real Mutex support on top of the primitives to get the packet MUX to do the correct thing. Anyway, there was really not enough information in his request, or my potentially outdated knowledge of pthreads on HP-UX for me to recommend condition variables with the "wake one" semantics. But again, your point is 100% valid for the FreeBSD release version out there, and I *DID* recommend that he switch his application to FreeBSD. ;-). PS: BLISS is ignorance... Regards, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B97CE7E.ED6A3D0F>