This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I was wondering if JAVA threads acted the same way as C threads when it comes to Busy Waiting. I am not 100% knowledgable on Busy Waiting, but I do know that when a thread runs in C/C++ and the thread is told to sleep or wait the processor is still being used quite a bit, thus still eating resources. So does JAVA act the same way? I mean, more so than what the VM is using the processor for? Hope that makes sense. Thanks
Oddly enough though, C does tax the processor. That is why they call it Busy Waiting. Like I said, I don't know all the ins and outs of it, however, I know that Busy Waiting exists, and I am wanting to know if it exists in JAVA Threads as it does in C Threads. Thanks for replying though.
In response to threads, here you go. First off Java threads are in theory a package included with Java and the API. Whatever host specific mechanisms Java decided to employ, are up to them and you need to read the spec and more importantly the system specifications. There are no such things as C threads. The "c threads" you are replying to are a library which is typically referred to as pthreads. I know that unix has these libraries, and do not know what other operating systems decided to implement (but most unix and linux OS distributions have it). Now when it comes to threads there are user based threads and kernel threads (lightweight processes). User threads are the pthread library and utilize a set of libraries that are managed by a set of running code, which can be inefficent. Now when it comes to kernel threads the kernel and subsystem is able to have low level code which is tightly tied to the operating system, and can typically run very smooth, or be a nightmare. So pthreads are user level threads, and they run on top of the OS as a application solution. Now some operating systems decide to do a maping of kernel level threads to user (pthread) threads, which can be more efficent. This model can be a one-to-one mapping, one-to-many, and/or one-to-none. So as you can tell there are no C threads, but a library which allows you to link and load with this standard (usually compiled and linked on unix with gcc to the pthread object file). So when you say thread, there is the Java thread which is part of the API and dealed with by the JVM, and don't quote me but it looks like JAVA has implemented their own thread libraries (similar to the pthread idea). Hope this helps now when it comes to the "c threads" they are that library set of code which self mantains itself. So if you tell a thread to block or sleep, the library will stop execution of that thread and move to another. Now if all your threads are waiting or blocked on a mutex or system resource, then its up to the specifics of their algorithms to determine what should occur. Now the JVM (being a user level software solution) also has these similar attributes. So you can see that when you are using code to manage threads at the user level you never get the operating level (kernel thread) behavior you wish for. So it could be that when you have little or nothing to do in C or the JVM that they busy wait (being the fact that there is nothing else to do). Busy waiting is usually if you have nothing to do, are waiting on a device, or just want to sleep, you go into a loop of no-ops for a duration, or you run a no-ops loop for a while and at the end of each time check some flag or indicator bit to see if the resource or "check condition" is OK to move on. Slicker ways of non-busy waiting is to interact with the system calls so that when you want to rest or be notified of an event, you let the operating system do it so only the OS code matters, according to your code you are not busy waiting or pooling. [ June 19, 2002: Message edited by: jango fett ]