* David Hanley <d...@ncgr.org> | And perhaps more critically: the ability to make use of more than one | CPU if present.
yet this may be what slows down the threads and speeds up the processes.
I think a valuable benchmarking approach would be test the same kind of communication between the various kinds of processes, like sockets and some simple protocol.
Joe Marshall <jmarsh...@alum.mit.edu> writes: > In *practice*, the sort of events a thread might find `interesting' > might not be easily described to the OS. For instance, you might want > a thread to wait until a particular lisp symbol has a value of NIL. > In a case like this (unless something *extraordinarily* clever is > going on), you have little recourse but to ask the scheduler to check > the value of the symbol periodically. It would be difficult to > persuade unix to do this, but rather trivial if you wrote your own > scheduler.
But the main Lisp process can still send an asynch event to wake up the thread that was sleeping.
Of course, some would instinctively say that this adds another level of indirection, but I don't think that the argument above is valid.
If you have a Lisp-based threading system (i.e. non-OS threads), and you wanted a thread to wake up when a symbol got bound, for example, then what's the difference between the Lisp process (which is scheduled identically to threads in Linux, for example) sees the boundp and wakes up the "thread" (as a stack group) vs. sending some kind of interrupt or event to another process-like thread to wake it up.
If you think about all this all over again, you'll probably see that the better thing all around is to use OS threads, when possible.
The reason for this has a lot to do with the subtle differences between OSs. The people who understand the OS very well probably are the best ones to take advantage of low-level, subtle optimizations that, at the Lisp level, are unreachable. Also, pushing off responsibility (e.g. scheduling) is a good thing, especially if you consider what KMP once said which is that it's not good to code [Lisp] to use local Lisp-level optimizations; it's better to write nice, elegant, simple code and use tools (I think he was referring to the LOOP macro in some way) when just do it, and don't try too hard to figure out if the system you're on does it well. For example, in this case, if the Lisp guys relied on the OS guys to make (future) improvements in multithreading, then I'd be happy to use a slightly less efficient implementation now, knowing that it would get better and better as the OS (in this case Linux) gets better (with respect to threads). The bottom line is for the Lisp implementor NOT to try too hard to figure out if the system he's on has multiple processors, etc. If there's a mechanism to abstract that away, then they should use it, unless the advantages to breaking into the guts reaps massive rewards.
> In *practice*, the OS scheduler could be very poorly implemented.
> So you have to find a balance between the expressive power you need to > describe your thread synchronization and the actual efficiency of the > OS scheduler.
again, even if this is so, the implementors should assume that the OS guys knew what they were doing. Even if they didn't do the best job, it's inevitably going to improve.
* Erik Naggum wrote: > I'd also expect Sun to want a "favorable demo" effect that shows this. > Linux has made fork exceptionally fast (my experience is that PIDs are > used up about three times faster under Linux than under SunOS 4.1.3_U1, > with equivalent work being performed on the systems), and has implemented > the performance sensitive parts of vfork in fork. ironically, it now > appears that threads have to do _more_ work than processes because they > _share_ the memory and a bunch of other stuff that fork splits off into > objects with distinct identity.
I doubt performance of sunos 4.1.3 says anything about recent solaris as that was before all the multiprocessor support in sunos 5 (I'm not even sure how much code they share, probably very little). However I'm not interested in performance comparisons between the systems (I'm sure linux is quicker on any small machine, but almost anything is fast enough now unless you have to run Word or something), I was kind of trying to point out that the benchmark was spurious.
>>>> In message <ey37lecamdv....@cley.com> >>>> On the subject of "Re: more questions about threads..." >>>> Sent on 05 Apr 2000 11:10:52 +0100 >>>> Honorable Tim Bradshaw <t...@cley.com> writes:
>> >> It looks to me like all the lisp threading APIs are similar enough >> that it's impossible to write code that will port reasonably easily >> from one to the other though.
-- Sam Steingold (http://www.podval.org/~sds) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. The only time you have too much fuel is when you're on fire.
* Tim Bradshaw <t...@cley.com> | I doubt performance of sunos 4.1.3 says anything about recent solaris | as that was before all the multiprocessor support in sunos 5 (I'm not | even sure how much code they share, probably very little).
note that I was talking about the consumption of PIDs, not performance. this has to do with the number of scripts and invoked interpreters and such, which may or may not impact performance. what I was suggesting was that Linux is very heavily script-and-interpreters-oriented, while BSD- based Unices have traditionally been less so than AT&T-based Unices, for whatever this is worth. in any case, I would expect Linux to be faster at forking _because_ it is used so much more. Linux was heavily into this mode of thinking long before it had SMP support.
> > Gah, bad wording; linux threads are lightweight compared to processes > > - if your benchmark used fork it would presumably be even slower - but > > heavywieght compared to most userland threads.
> Actually it is the other way around! The same benchmark using fork > is 10 times faster than the one using LinuxThreads. Here are the > timings on a 600MHz Athlon with Linux RH 6.1:
I believe I read a quote from the linux-kernel developers once stating that there wouldn't be put much effort into making threads effective, as they regarded heavy use of threads to be bad design in the first place. (No, I don't have a reference)
Your benchmark only compares thread-creation - what is with the speed and quality of the locking-mechanisms or the context-switch times??? Productionready Code doesn't simply create some threads from the threading system - You should use thread-pools so that the tread-creation-time would be obvious. As I remember the actual implementation of fork in linux is only a compatibility-wrapper around LinuxTreads (particularily the "clone()" system-call) Linuxthreads have to manage cloning of filedescriptors and much more OS-level stuff than User-Space-Threads have.
> > Marc Feeley <fee...@trex.IRO.UMontreal.CA> writes:
> > > I don't think the term "lightweight" is appropriate for Linux threads > > > because they involve the OS kernel for scheduling, process creation > > > etc.
> > Gah, bad wording; linux threads are lightweight compared to processes > > - if your benchmark used fork it would presumably be even slower - but > > heavywieght compared to most userland threads.
> Actually it is the other way around! The same benchmark using fork > is 10 times faster than the one using LinuxThreads. Here are the > timings on a 600MHz Athlon with Linux RH 6.1:
In article <ukwln2stkti....@pvv.org>, Rolf Rander Naess <rolfn+n...@pvv.org> wrote:
> I believe I read a quote from the linux-kernel developers once stating > that there wouldn't be put much effort into making threads effective, > as they regarded heavy use of threads to be bad design in the first > place. (No, I don't have a reference)
Wow. That's a pretty extreme position. Personally, I'd like an OS that lets me decide what *I* want to do. I don't have multithreaded Lisp experience, but work in Java, where threads are part of the standard language, and they are invaluable in making responsive, robust systems without complicated coupling between separate parts of the program. So they often help *good design*.
They certainly have a cost - they were a major source of errors until we became experienced with suitable patterns - but so do many other useful, powerful ideas in computing. (I'd say they need an extra level of abstraction, but I don't know what it is yet).
Maybe it was in a particular context, or a long time ago....
I wasn't arguing that lisp-level threads were unconditionally superior to OS threads, just that there are cases where OS threads may not have the necessary functionality or performance, or cases where Lisp threads have poor performance. You have to evaluate the benefits of each on a case by case basis. In a perfect world, OS threads would win hands down, but the world is far from perfect.
David Bakhash <ca...@alum.mit.edu> writes: > Joe Marshall <jmarsh...@alum.mit.edu> writes:
> > In *practice*, the sort of events a thread might find `interesting' > > might not be easily described to the OS. For instance, you might want > > a thread to wait until a particular lisp symbol has a value of NIL. > > In a case like this (unless something *extraordinarily* clever is > > going on), you have little recourse but to ask the scheduler to check > > the value of the symbol periodically. It would be difficult to > > persuade unix to do this, but rather trivial if you wrote your own > > scheduler.
> But the main Lisp process can still send an asynch event to wake up > the thread that was sleeping.
Let's make a more concrete example. Suppose we have a lisp process servicing http requests. While it is serving such a request, it binds a special variable *HTTP-REQUEST-BEING-SERVICED* to T.
Now suppose we have another process that cannot begin some sort of action if an http-request is being serviced. The code for this process might have a fragment like this in it:
(progn (process-wait "waiting for http to be done" #'(lambda () (not *http-request-being-serviced*))) (begin-some-action))
(yes, there is a race condition here. Ignore it.)
PROCESS-WAIT, or something like it, is typically found in lisp multi-threading packages. It tells the scheduler to put this process to sleep until the function returns T. The scheduler is supposed to evaluate the function from time to time.
Finally, suppose yet another process is listening to the serial port. It is using some sort of magic involving the OS.
This third process is using an OS thread in the most effective manner. Provided the OS is clever, it doesn't need to consider scheduling the thread or look at the thread resources *at all* until a serial line interrupt occurs.
The second process, however, doesn't have it so lucky. Someone, either the process itself or a scheduling process, has to periodically peek at the value of *http-request-being-serviced*. This process has to be in lisp because we can't indicate to the OS that we're waiting on a symbol binding. This also cannot be the process servicing the http port because it is busy with other things. (Let's not violate abstraction by rewriting the http service routine to handle synchronization of multiple unrelated threads.)
So we have a lisp process polling the value of *http-request-being-serviced*. The OS doesn't know under what conditions this might happen, as far as it is concerned, this is a running thread and must be considered when processes are scheduled.
> If you have a Lisp-based threading system (i.e. non-OS threads), and > you wanted a thread to wake up when a symbol got bound, for example, > then what's the difference between the Lisp process (which is > scheduled identically to threads in Linux, for example) sees the > boundp and wakes up the "thread" (as a stack group) vs. sending some > kind of interrupt or event to another process-like thread to wake it > up.
I don't know how threads are scheduled in Linux. If they are scheduled with a simple `round robin' type of scheduler that simply polls pending OS-level events, then it really wouldn't make much difference.
On the other hand, suppose each thread on the OS is awaiting some form of I/O. The OS can simply turn off the scheduler until an interrupt comes in. Or suppose that all threads but one is awaiting I/O. The OS can transfer all CPU time to that thread.
> If you think about all this all over again, you'll probably see that > the better thing all around is to use OS threads, when possible.
Not necessarily.
> The reason for this has a lot to do with the subtle differences > between OSs.
An ideal reason to use lisp-level threads: it is more likely to present a uniform interface.
> The people who understand the OS very well probably are > the best ones to take advantage of low-level, subtle optimizations > that, at the Lisp level, are unreachable.
An ideal reason to use OS threads.
> Also, pushing off > responsibility (e.g. scheduling) is a good thing, especially if you > consider what KMP once said which is that it's not good to code [Lisp] > to use local Lisp-level optimizations;
Again, a tradeoff. If you want portable, high-level code, of course not. If portability is not an issue and performance (and correctness) is, then why not.
> it's better to write nice, > elegant, simple code and use tools (I think he was referring to the > LOOP macro in some way) when just do it, and don't try too hard to > figure out if the system you're on does it well.
Yes. You shouldn't re-invent the wheel.
But suppose the system you're on doesn't do it well enough? Or does it wrong?
> For example, in this > case, if the Lisp guys relied on the OS guys to make (future) > improvements in multithreading, then I'd be happy to use a slightly > less efficient implementation now, knowing that it would get better > and better as the OS (in this case Linux) gets better (with respect to > threads). The bottom line is for the Lisp implementor NOT to try too > hard to figure out if the system he's on has multiple processors, > etc. If there's a mechanism to abstract that away, then they should > use it, unless the advantages to breaking into the guts reaps massive > rewards.
Again, in *theory* this is correct. Reality often rears its ugly head, though.
> > In *practice*, the OS scheduler could be very poorly implemented.
> > So you have to find a balance between the expressive power you need to > > describe your thread synchronization and the actual efficiency of the > > OS scheduler.
> again, even if this is so, the implementors should assume that the OS > guys knew what they were doing.
Even if the OS is Unix or NT? I don't think so.
> Even if they didn't do the best job, > it's inevitably going to improve.
You have got to be kidding! Unix is about 25 years old and it *still* doesn't handle pcluser'ing correctly. It still runs fsck at boot time. NFS still has no cache coherency.
Or look at Windows 2000. Is 30 million lines of code an improvement?
* Andrew Cooke <and...@andrewcooke.free-online.co.uk> | I don't have multithreaded Lisp experience, but work in Java, where | threads are part of the standard language, and they are invaluable in | making responsive, robust systems without complicated coupling between | separate parts of the program. So they often help *good design*.
you don't need OS support to make this work the way you want. the desire for OS support can often lead you to dismiss what you can actually do as "undesirable". many would-be CL users have run into this "mindset trap" where they refuse to use Common Lisp because they have this fixation that some feature or another must be "standard" before they can use it.
investigate your Common Lisp environment. programming only in Common Lisp as per the standard _only_ is like programming in any other language as per the standard _only_ (with the exception that you can actually get quite a lot of interesting work done in standard CL) -- ignoring the programming environment (such as Allegro CL for CL, and Unix for C) is just plain stupid.
Joe Marshall wrote: > "dave" <deeno...@yahoo.com> writes:
> > My guess is that OS threads would be better, in that you don't have to > > re-invent an efficient scheduler, and also that you can take better > > advantage of nuggets in the kernel of whatever OS you're operating on.
> In *theory*, most of the threads aren't doing much but waiting around > for something interesting to happen.
Not for every app. I have an app which runs on a multiple CPU machine, and needs to generate a number of images ( time intensive ). I shoot off a number of threads to work on the image ( one each ) and this makes the whole thing happen a *lot* faster.
> The OS is the ultimate oracle > for interesting events, so in *theory*, the OS can schedule things > *very* efficiently. But....
> In *practice*, the sort of events a thread might find `interesting' > might not be easily described to the OS. For instance, you might want > a thread to wait until a particular lisp symbol has a value of NIL. > In a case like this (unless something *extraordinarily* clever is > going on), you have little recourse but to ask the scheduler to check > the value of the symbol periodically. It would be difficult to > persuade unix to do this, but rather trivial if you wrote your own > scheduler.
What your scheduler is going to do, then is (while *waiting-flag* (sleep 5))
Which you can do in lisp, and still use the system threads.
> In *practice*, the OS scheduler could be very poorly implemented.
That's true, it could. If so, it's likely you're going to have *other* performance issues, and still not use more than one CPU if present.
Erik Naggum wrote: > * David Hanley <d...@ncgr.org> > | And perhaps more critically: the ability to make use of more than one > | CPU if present.
> yet this may be what slows down the threads and speeds up the processes.
This is true, particularly if you're doing a lot of memory allocation. It depends a *lot* on the task at hand. However, I don't think it justifies using some homebrewed version of threads instead of OS threads, though.
Here: Java used/uses homebrewed "green" threads. We dont't want to be like java, do we? :)
David Hanley <d...@ncgr.org> writes: > Joe Marshall wrote:
> > In *theory*, most of the threads aren't doing much but waiting around > > for something interesting to happen.
> Not for every app. I have an app which runs on a multiple CPU > machine, and needs to generate a number of images ( time intensive ). > I shoot off a number of threads to work on the image ( one each ) > and this makes the whole thing happen a *lot* faster.
> > The OS is the ultimate oracle > > for interesting events, so in *theory*, the OS can schedule things > > *very* efficiently. But....
> > In *practice*, the sort of events a thread might find `interesting' > > might not be easily described to the OS. For instance, you might want > > a thread to wait until a particular lisp symbol has a value of NIL. > > In a case like this (unless something *extraordinarily* clever is > > going on), you have little recourse but to ask the scheduler to check > > the value of the symbol periodically. It would be difficult to > > persuade unix to do this, but rather trivial if you wrote your own > > scheduler.
> What your scheduler is going to do, then is > (while *waiting-flag* > (sleep 5))
> Which you can do in lisp, and still use the system threads.
Yes, but you don't get all the benefits of OS threads. You'd have a thread that unconditionally wakes up every five seconds (and gets swapped in). If you were waiting on something the OS is familiar with (like an i/o event) the OS wouldn't even bother with your thread until it was actually runnable.
> > In *practice*, the OS scheduler could be very poorly implemented.
> That's true, it could. If so, it's likely you're going to have *other* > performance issues, and still not use more than one CPU if present.
I was thinking of bugs and race conditions more than performance. Certainly if you want to use multiple cpu's, you are almost required to use OS threads (unless there is some funky mechanism that lets you gain control of the other cpus directly).
> I believe I read a quote from the linux-kernel developers once stating > that there wouldn't be put much effort into making threads effective, > as they regarded heavy use of threads to be bad design in the first > place. (No, I don't have a reference)
References? (BeOS is a good counterexample to this opinion, BTW.) -- mailto:j...@acm.org phone:+49-7031-464-7698 (HP TELNET 778-7698) http://www.bawue.de/~jjk/ fax:+49-7031-464-7351 PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish, 0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
Joe Marshall wrote: > A real good argument for OS threads.
This depends what you mean by OS threads. A lightweight thread implementation which is supplied withing the OS but keeps the threads within a single process memory and resources will not be affected by whether you have 1 or 87 cpus.
> This depends what you mean by OS threads. A lightweight thread implementation > which is supplied withing the OS but keeps the threads within a single process > memory and resources will not be affected by whether you have 1 or 87
cpus.
I don't think that OS threads are limited to run on one CPU. At least it's not the case under NT. There are even functions to specify on which processors can and should a thread run.
The SetThreadIdealProcessor function is used to specify a preferred processor for a thread. The system schedules threads on their preferred processors whenever possible.
The SetThreadAffinityMask function sets a processor affinity mask for a specified thread. A thread affinity mask is a bit vector in which each bit represents the processors that a thread is allowed to run on.
Marc Battyani wrote: > I don't think that OS threads are limited to run on one CPU.
Which is not what I tried to say. What I was trying to say is that there are implementations of OS threads (looking at UNIX which I know a little more about than NT) in which you *are* limited to run on one CPU. This is because although the thread is supplied by the OS (that is the operation comes bundled with the kernel [1]) the thread operations are limited to run in user and not kernel space. As user processes generally do not have access to the SMP/kernel scheduler, the OS thread is limited to run on the CPU on which the user process runs. Thread scheduling is then handled within the user process. This is a pretty bad way of implementing threads but such implementations *do* exist.
This is contrast to system in which the thread system is implemented in such as way to give access to kernel space at which point threads can be happily fired off onto whatever CPU is free. Thread scheduling is then handled by the kernel. However, this again this is somewhat problematic as these threads are very similar to processes. (A way round this is to have some hybrid system that has some happy mixture of the light-weight user-thread system and the heavy-weight kernel-thread.)
Anyway, maybe its just *me* that is confused and but I am fairly sure that I am not that unique. So my problem with this thread thread (sic) is the confusion as to what threads are, the jargon used to describe them and how this maps to the way in which they are implemented. For example: the differences OS threads, green threads, kernel threads, light and heavy threads, nice threads &c ;)
Cheers,
:) will
[1] and the reason why I was asking for a definition of an OS thread. If an OS thread is `a thread that has access to kernel space' then you have defined away the problems.
Joe Marshall wrote: > The second process, however, doesn't have it so lucky. Someone, > either the process itself or a scheduling process, has to periodically > peek at the value of *http-request-being-serviced*. This process has > to be in lisp because we can't indicate to the OS that we're waiting > on a symbol binding. This also cannot be the process servicing the > http port because it is busy with other things. (Let's not violate > abstraction by rewriting the http service routine to handle > synchronization of multiple unrelated threads.)
> So we have a lisp process polling the value of > *http-request-being-serviced*. The OS doesn't know under what > conditions this might happen, as far as it is concerned, this is a > running thread and must be considered when processes are scheduled.
This means Lisp globals should be implemented using condition variables (better yet, do not support their use for synchronization unless a corresponding (nonignorable) declaration has been performed)
-- Fernando D. Mato Mira Real-Time SW Eng & Networking Advanced Systems Engineering Division CSEM Jaquet-Droz 1 email: matomira AT acm DOT org CH-2007 Neuchatel tel: +41 (32) 720-5157 Switzerland FAX: +41 (32) 720-5720
> (No, I don't have a reference) Jens Kilian <Jens_Kil...@agilent.com> writes: > References?
Well, duh. Seems I have to increase my caffeine intake. Sorry. -- mailto:j...@acm.org phone:+49-7031-464-7698 (HP TELNET 778-7698) http://www.bawue.de/~jjk/ fax:+49-7031-464-7351 PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish, 0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
* David Hanley <d...@ncgr.org> | Not for every app. I have an app which runs on a multiple CPU machine, | and needs to generate a number of images ( time intensive ). I shoot off | a number of threads to work on the image ( one each ) and this makes the | whole thing happen a *lot* faster.
how do they communicate the results back to eachother or a master?
> This depends what you mean by OS threads. A lightweight thread implementation > which is supplied withing the OS but keeps the threads within a single process > memory and resources will not be affected by whether you have 1 or 87 cpus.
True, with a sufficently stupid implementation. I draw a parallel to "lisp is slow" arguments, by pointing to croddy lisp implementations.
Erik Naggum wrote: > * David Hanley <d...@ncgr.org> > | Not for every app. I have an app which runs on a multiple CPU machine, > | and needs to generate a number of images ( time intensive ). I shoot off > | a number of threads to work on the image ( one each ) and this makes the > | whole thing happen a *lot* faster.
> how do they communicate the results back to eachother or a master?
They each get an object to modify, and call a synchronized reporting function when they are complete, which calls another function when every thread has reported in.
Unfortunately, processes wouldn't work well for this. The images have to come back to one place, and it's prohibitively expensive to send an image via IPC in java, and, of course, java has no shared memory. The threads do not have to communicate with each other once they are started, though they do have to make sure someone isn't already generating a resource they need (conflict). If someone else is, they wait for it. It took awhile to get right, but it's worth it, and I learned quite a bit about threaded caching. :)
Joe Marshall wrote: > David Hanley <d...@ncgr.org> writes:
> > What your scheduler is going to do, then is > > (while *waiting-flag* > > (sleep 5))
> > Which you can do in lisp, and still use the system threads.
> Yes, but you don't get all the benefits of OS threads. You'd have a > thread that unconditionally wakes up every five seconds (and gets > swapped in). If you were waiting on something the OS is familiar with > (like an i/o event) the OS wouldn't even bother with your thread until > it was actually runnable.
Yes, but the OS os going to do something almost exactly like the above, is my point. If it takes place in the OS space or the user space doesn't make a huge amount of difference.
Actually in clos, you could put an :after method on the stetter of that flag and have that wake up the thread.. Even more efficient.
> I was thinking of bugs and race conditions more than performance. > Certainly if you want to use multiple cpu's, you are almost required > to use OS threads (unless there is some funky mechanism that lets you > gain control of the other cpus directly).
You're right, you will have less potential and real threading bugs using non-os threads. I still wouldn't trust such code, however. Suppose your compiler is upgraded to use OS threads, and all the code breaks? Or you port to a certian platform? It's also true, as you say ( I think ) that OS thread could cause more system problems too. I say, get the system right.
On a tangent, there were bugs in java's stop() of a thread, so it is deprecated, and will be removed. They say a thead should programmatically test a stop flag periodically if someone else may need to kill it. This is a *really horrible* idea. Flag checks take up time, potentially a lot, and what if you're calling long-running library code? Geez.
I'm going to chime in, as half the things I have read here go against everything I have learned about threading and concurrent programming. That may well be because I haven't done that much of it, so this might turn out to be an interesting learning experience. Please don't take the rest of this message as preaching, I'm merely regurgitating what I remember. Feel free to correct me :-)
The OS attempts to provide a generic level of functionality that works well across a variety of applications. Sometimes, the OS characteristics match the application well, and sometimes not. If not, we often find ourselves tweaking the OS/kernel to get better performance. That is true of threading as well.
OS threads have to be scheduled by the kernel. Each time such scheduling takes place, the previous thread's context has to be saved by the kernel, the next thread's context restored, and the thread started. This makes OS threads rather crufty. They turn out to be great for dividing work within a process where there isn't that much interaction between the parts. This is often the case, for example, in image processing and handling HTTP requests. An area of an image can be handed over to different OS threads, which can now potentially run on multiple CPU's. The same with different threads handling different HTTP requests. There is sometimes a large cost in collating results through IPC, but that's a one time cost. Overall, performance is much improved.
This also shows the problems with OS level threads. If the threads have to be closely synchronized when they run, then user threads are preferable. Consider the consumer/producer problem, where there is one thread acting as a listener on an intermittent stream (for example user input), and a worker thread collecting data from the listener thread when it has time. The turn-around time for such coordination has to be relatively short, otherwise we will probably find a rather frustrated user. In the absence of shared memory, we incur yet more overhead in getting stuff from the listener to the worker. The context switch that would be necessary in using OS threads would slow down the application substantially.
Another problem with user threads is that if one thread in the user process blocks on an OS call, the entire process blocks. That sometimes is unavoidable and unacceptable. In such a situation, we again turn to OS threads, so that the entire process cannot be blocked from just one call.
I've heard rumblings about lightweight OS threads that don't require a full context switch and some such, but I don't know much about this at all. Yes, they would be more efficient, but still not as efficient as user threads. Simply because the process knows better than the OS what its scheduling requirements are.
Comments welcome.
Sunil
In article <38ECC298.1356A...@ncgr.org>, David Hanley <d...@ncgr.org> wrote:
> > * David Hanley <d...@ncgr.org> > > | Not for every app. I have an app which runs on a multiple CPU machine, > > | and needs to generate a number of images ( time intensive ). I shoot off > > | a number of threads to work on the image ( one each ) and this makes the > > | whole thing happen a *lot* faster.
> > how do they communicate the results back to eachother or a master?
> They each get an object to modify, and call a synchronized reporting function > when they are complete, which calls another function when every thread has > reported in.
> Unfortunately, processes wouldn't work well for this. The images have to come > back to one place, and it's prohibitively expensive to send an image via IPC > in java, and, of course, java has no shared memory. The threads do > not have to communicate with each other once they are started, though they > do have to make sure someone isn't already generating a resource they need > (conflict). If someone else is, they wait for it. It took awhile to get right, > but > it's worth it, and I learned quite a bit about threaded caching. :)
> dave
-- Sunil Mishra ** www.everest.com All messages sent to the above email account shall go unread.
