Is it true that if I am using multi-threading Thread.yield() (which I think puts a thread in a runnable/ready to run state) would NOT release any monitor/mutext/lock that the Thread currently owns?
This is true. Basically causing a Thread to yield is playing nice. An example is if you have a GUI thread that has just prompted the user for input than it stands to reason that there is no purpose for the GUI Thread to continue to hold the CPU. The chances are that it will take a second or two for the user to actually input the necessary data, this is a lot of CPU time that is wasted if your Thread is just sitting there spinning its wheels. A better design would be to yield the CPU since you don't actually need it and allow other Threads to execute. The drawback is that if the GUI Thread holds an important monitor than it could be blocking other Threads from execution but in this case it doesn't matter because we were going to be waiting anyways. Obviously explicitly calling yield is not advantageous in all cases. Regardless, even if you do not ever explicitly call yield the JVM is going to timeslice the different based on their priority. It is not like in C when you needed to explicitly control threading in your code if the OS didn't support it (okay so POSIX threading was at least better than this). It doesn't matter if the OS supports threads or not the JVM will emulate a multi-threaded system. A great thing about Java is that threading is directly built into the language so it is very easy to take advantage of. The drawback is that it is very easy to abuse as well.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.