Re: Posix Threading
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 [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Posix Threading
Hi All, I am trying to create threads under HP-UX 11 using POSIX threads library and using the method pthread_create(...). But I don't know how can I create a thread in a suspended state. Thanks in advance Ullasan --- This email message (including any attachment) is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the addressee, you may not disclose it, copy it, distribute it or take or omit to take any action on foot of it. Any such act or omission is prohibited and may be unlawful. This message (including any attachment) is transmitted for discussion purposes only. It is protected by copyright laws and it has no other legal or contractual standing. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Posix Threading
On Wed, Sep 05, 2001 at 04:18:19PM +0100, [EMAIL PROTECTED] wrote: Hi All, I am trying to create threads under HP-UX 11 using POSIX threads library and using the method pthread_create(...). But I don't know how can I create a thread in a suspended state. Thanks in advance This mailing list is a forum for discussion related to the development of the FreeBSD operating system, so it probably isn't the best place to ask HP-UX specific questions. -- garrett rooney Unix was not designed to stop you from [EMAIL PROTECTED] doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Posix Threading
[EMAIL PROTECTED] wrote: Hi All, I am trying to create threads under HP-UX 11 using POSIX threads library and using the method pthread_create(...). But I don't know how can I create a thread in a suspended state. First the obligatory off topic humor: This is not the place to ask about HP-UX programming; you probably want the Hewlet-Compaqard user's mailing list... 8-p. -- You don't give us enough information about your application for us to tell you the correct approach to building it; you've started with a hammer (initially suspended threads) and are ignoring other tools (e.g. the jaws of life) in your search for a way to instance your hammer, under the theory that your problem is a nail (it might not be; you've given us no way to know). Probably switching to FreeBSD and the kqueue interface would better match your problem. Let's do some setup, and then guess at what you wanted to do, and give you several approaches to our satisfying our guesses... Short answer: You can't. The suspended state is an attribute of the thread that is controlled by the threads scheduler, and is not directly controllable by you. A thread is guaranteed to be suspended only when it is waiting on a mutex, condition variable, or blocking call (such as I/O). I suggest you rethink your design. If the intent is to get an immediate context switch back to yourself, you will need to create a mutex that can not be acquired by the newly created thread, and attempt to acquire it as the first thing you do. You can then immediately release it so as not to block other threads trying the same dirty trick. Note that there is not an explicit yield, so you will have to do something like this to get a yield equivalent. Alternately, if the intent is to create threads so that they will be around when you need them, you would be better off delaying their creation until you need them. The expensive part of threads creation is _supposed_ to be the allocation of the stack; so if you keep a pool of preallocated stacks lying around for your use, you will get only a small startup latency. 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). If the intent is a horse race, where you create a bunch of threads, and then open the starting gate and have them all start going ``at once'', then you want a condition variable. I intentionally quoted ``at once'', since the concurrency will not be real without multiple CPUs and cooperation from the OS, it will be virtual -- just as if you were running multiple processes, instead of trying to use threads. This is an artifact of the scheduler, and varies from implementation to implementation. Note: I don't know what level of standards compliance the HP-UX 11 version of pthreads has achieved; some of the things described above are probably not going to be easy to achieve in downrev versions of the library. Last time I looked, the HP-UX version of pthreads was a Draft-4 version, not a Draft-10 or standard version, so you may be in more trouble than you originally thought; specifically, you will have a problem with creating a preinitialized mutex in a Draft-4 version of pthreads, so you will have to create the mutex (if you use one) first. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Posix Threading
On 05-Sep-01 Terry Lambert wrote: [EMAIL PROTECTED] wrote: Hi All, I am trying to create threads under HP-UX 11 using POSIX threads library and using the method pthread_create(...). But I don't know how can I create a thread in a suspended state. First the obligatory off topic humor: This is not the place to ask about HP-UX programming; you probably want the Hewlet-Compaqard user's mailing list... 8-p. -- You don't give us enough information about your application for us to tell you the correct approach to building it; you've started with a hammer (initially suspended threads) and are ignoring other tools (e.g. the jaws of life) in your search for a way to instance your hammer, under the theory that your problem is a nail (it might not be; you've given us no way to know). Probably switching to FreeBSD and the kqueue interface would better match your problem. Let's do some setup, and then guess at what you wanted to do, and give you several approaches to our satisfying our guesses... Short answer: You can't. The suspended state is an attribute of the thread that is controlled by the threads scheduler, and is not directly controllable by you. A thread is guaranteed to be suspended only when it is waiting on a mutex, condition variable, or blocking call (such as I/O). I suggest you rethink your design. If the intent is to get an immediate context switch back to yourself, you will need to create a mutex that can not be acquired by the newly created thread, and attempt to acquire it as the first thing you do. You can then immediately release it so as not to block other threads trying the same dirty trick. Note that there is not an explicit yield, so you will have to do something like this to get a yield equivalent. Alternately, if the intent is to create threads so that they will be around when you need them, you would be better off delaying their creation until you need them. The expensive part of threads creation is _supposed_ to be the allocation of the stack; so if you keep a pool of preallocated stacks lying around for your use, you will get only a small startup latency. 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). If the intent is a horse race, where you create a bunch of threads, and then open the starting gate and have them all start going ``at once'', then you want a condition variable. I intentionally quoted ``at once'', since the concurrency will not be real without multiple CPUs and cooperation from the OS, it will be virtual -- just as if you were running multiple processes, instead of trying to use threads. This is an artifact of the scheduler, and varies from implementation to implementation. Note: I don't know what level of standards compliance the HP-UX 11 version of pthreads has achieved; some of the things described above are probably not going to be easy to achieve in downrev versions of the library. Last time I looked, the HP-UX version of pthreads was a Draft-4 version, not a Draft-10 or standard version, so you may be in more trouble than you originally thought; specifically, you will have a problem with creating a preinitialized mutex in a Draft-4 version of pthreads, so you will have to create the mutex (if you use one) first. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Posix Threading
[ I really hate it when my window manager gets stuck in a loop spinning while I'm composing a mail message and I forget to fix up the mail message. *sigh* ] On 05-Sep-01 Terry Lambert wrote: [EMAIL PROTECTED] wrote: Hi All, I am trying to create threads under HP-UX 11 using POSIX threads library and using the method pthread_create(...). But I don't know how can I create a thread in a suspended state. First the obligatory off topic humor: This is not the place to ask about HP-UX programming; you probably want the Hewlet-Compaqard user's mailing list... 8-p. -- 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. PTHREAD_COND_SIGNAL(3) FreeBSD Library Functions Manual PTHREAD_COND_SIGNAL(3) SYNOPSIS #include pthread.h int pthread_cond_signal(pthread_cond_t *cond); DESCRIPTION The pthread_cond_signal() function unblocks one thread waiting for the condition variable cond. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
