On the necessity of threads having sleep time...
fgu...@gmail.com
language. I'm a newbie when it comes to thread programming.
Here is a quote from an instructional article on a website...
"Note that it is important to sleep somewhere in a thread. If not, the
thread will consume all CPU time for the process and will not allow
any other methods such as threads to be executed."
I don't quite follow. If the purpose of threads is to allow for
multitasking and sharing of resources, then why do you have to give a
thread sleep time in order for other threads to work? Doesn't that
kind of defeat the purpose?
here is my source for the quote.
http://www.javaworld.com/javaworld/jw-04-1996/jw-04-threads.html?page=1
Eric Sosman
The same article also recommends using the stop() and
suspend() methods -- both of which have been deprecated
almost since their invention -- so I think you would be
justified in viewing the writer's opinions with skepticism.
For what it's worth, I think his notions about sleep() are
ill-informed and should be ignored.
But don't take it from me: ask the threading experts.
Lots of them hang out on comp.programming.threads, which is
mostly about C and C++ but has a good deal of language-
independent content as well, and even a little bit of Java.
Try your question there; you may find it instructive.
--
Eric Sosman
eso...@ieee-dot-org.invalid
fgu...@gmail.com
>
> But don't take it from me: ask the threading experts.
> Lots of them hang out on comp.programming.threads, which is
> mostly about C and C++ but has a good deal of language-
> independent content as well, and even a little bit of Java.
> Try your question there; you may find it instructive.
>
> --
> Eric Sosman
> esos...@ieee-dot-org.invalid
Thanks for the reply. I'll try what you said about ignoring his sleep
remarks and see how it goes. One thing though. You suggested I try my
question "there" on comp.programming threads, where lots of experts
hang out. I have no problem with that, except I thought this was
comp.programming.threads. At least that what I read at the top of the
page. :)
George Peter Staplin
That article has some flaws (as Eric has already pointed out). The features
it uses were deprecated in Java, because they are prone to causing
deadlocks.
See: http://java.sun.com/javase/6/docs/api/java/lang/Thread.html
One problem is that if your thread is constantly spinning and doing nothing
essentially while waiting for resources, that CPU core goes to waste, and
interactivity suffers.
If you structure your program's threads to make them react to events, you
can generally create a better application. For instance: you might have
one thread that read()s from client connections when a client has a
readable socket, and another that write()s pending data to clients.
If the writer thread has nothing to write(), you probably don't want it to
do be stuck in some while loop doing nothing, because those are just wasted
cycles. So you might have a pending queue of things to write, and the
writer would wait for something to become ready if there is no more work
for it to do.
There are also some rare situations where you wouldn't want any waiting or
blocking at all, because so many events occur routinely that the thread can
always do work. You would know if you need that, and my assumption is that
you don't.
-George
fgu...@gmail.com
wrote:
Yes, I did in fact notice that stop() was deprecated, no problem in
coming up with an alternative. Have the thread monitor a variable that
tells it when to stop.
I'll tell you what I have on the go. A little chess program that is a
learning project for me. It works well as a single threaded
application, except for two issues.
1. I have implemented a form of drag and drop for the human to move.
When the human finishes it's move, the board ( a JPanel with a paint()
method ) does not finish the redraw in a timely fashion because the
program is busy calculating its next move.
2. When it is the human's turn to move, the program is idle. I want
the program to think while it is waiting for me to move. So I have
planned to have the computer opponent run as a thread, that monitors a
boolean value that determines when it is it's turn to move. The board
implements a mouse listener, the MouseReleased() method that kicks in
when I drop a piece on a square sets the boolean variable that the
thread monitors.
So my question is, if the sleep remarks in the article are valid, it
would suggest that if my computer opponent is running as a thread even
when it is my turn, then I will not be able to move the pieces unless
I give the thread some sleep time, in order to free up some CPU to
allow me to move the piece. I suppose all I need to do is try both
methods, but I just thought I'd ask.
Anyways, I hope all this is clear, I have been know to be obtuse with
this kind of stuff.
Eric Sosman
> On Apr 25, 2:28 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>
>> But don't take it from me: ask the threading experts.
>> Lots of them hang out on comp.programming.threads, which is
>> mostly about C and C++ but has a good deal of language-
>> independent content as well, and even a little bit of Java.
>> Try your question there; you may find it instructive.
>
> remarks and see how it goes. One thing though. You suggested I try my
> question "there" on comp.programming threads, where lots of experts
> hang out. I have no problem with that, except I thought this was
> comp.programming.threads. At least that what I read at the top of the
> page. :)
Your top-of-page reading is (demonstrably) better than
mine! The article was about Java threads, I read a couple
of Java groups, I began to imagine myself answering a query
on one of those groups, the weather is warm and pleasant,
my mind wanders, >snore< ...
--
Eric Sosman
eso...@ieee-dot-org.invalid
Eric Sosman
> On Apr 25, 2:28 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>
>> But don't take it from me: ask the threading experts.
>> Lots of them hang out on comp.programming.threads, which is
>> mostly about C and C++ but has a good deal of language-
>> independent content as well, and even a little bit of Java.
>> Try your question there; you may find it instructive.
>
> remarks and see how it goes. One thing though. You suggested I try my
> question "there" on comp.programming threads, where lots of experts
> hang out. I have no problem with that, except I thought this was
> comp.programming.threads. At least that what I read at the top of the
> page. :)
Your top-of-page reading is (demonstrably) better than
David Schwartz
> I am currently studying Java, but I imagine this applies to any
> language. I'm a newbie when it comes to thread programming.
>
> Here is a quote from an instructional article on a website...
>
> "Note that it is important to sleep somewhere in a thread. If not, the
> thread will consume all CPU time for the process and will not allow
> any other methods such as threads to be executed."
This is bad advice. If one thread has an unlimited amount of work to
do, you can do no better than to do a finite portion of it.
> I don't quite follow. If the purpose of threads is to allow for
> multitasking and sharing of resources, then why do you have to give a
> thread sleep time in order for other threads to work? Doesn't that
> kind of defeat the purpose?
Not at all. It is the application programmer's responsibility to
ensure that, whatever thread(s) the implementation chooses to run, the
work that needs to be done gets done. If you care which threads run
and when they run, it is your responsibility to ensure that with
appropriate synchronization primitives.
If there is only a single CPU, it is actually most efficient to keep a
single thread running as long as possible, while its code and data is
warm in the caches. If that causes you a serious problem, it is your
responsibility to compel it to do otherwise.
DS
fgu...@gmail.com
David Schwartz
> food for thought David, and a different perspective. Thanks.
Let me add one more thought, responding to:
"If the purpose of threads is to allow for multitasking and sharing of
resources ..."
The purpose of threads is two-fold:
1) If one thread blocks, for some reason, the application as a whole
is not stalled. Threads allow your application to continue to make
forward progress even if it has to do something that is best done in a
blocking way.
2) If the implementation supports it and chooses to let you do it,
threads allow you to do more than one thing at at time. But they (in
most implementations) do not guarantee that you can do more than one
thing at a time, and the implementation chooses which thread will run
unless you compel it otherwise.
You should know the precise rules for the threading API you are using.
You should assume the worst choices on the part of the implementation.
If they break your application, your application is broken.
In POSIX-land, for example, you are guaranteed that if at least one of
your threads can make forward progress, it will run. However, unless
you specify thread priorities, you are not guaranteed any particular
order or time. (For example, the implementation may choose to always
run the ready-to-run thread has been around the longest. When a lock
is released, it may give it to the oldest thread if it wants to.)
If you have a thread that is always ready-to-run, it is perfectly
sensible for the implementation to always run that thread. If you
care, and you think that's bad, then your designed your program badly,
because it's doing work other than the work you most want done.
It is your responsibility to code your application so that it does the
work you need it it do. It is the implementation's responsibility to
run whichever thread(s) are most efficient.
DS
Dave Butenhof
> I am currently studying Java, but I imagine this applies to any
> language. I'm a newbie when it comes to thread programming.
>
> Here is a quote from an instructional article on a website...
See, that's one of the problems with the internet; anyone can post
opinions, whether malicious, obsolete, or merely uninformed, and someone
doing a search will find it.
In this case, though, there's another sometimes more insidious problem:
time. Information posted on the internet generally doesn't expire (and
even if it does, it's usually cached somewhere). Information can quickly
become MIS-information.
The article you reference is over 13 years old. (Dated 4/1/1996.) In
terms of wide-spread general purpose thread programming, this is early
colonial days; and in terms of Java, well, I think the web page
background should show large reptilian footprints...
> "Note that it is important to sleep somewhere in a thread. If not, the
> thread will consume all CPU time for the process and will not allow
> any other methods such as threads to be executed."
>
> I don't quite follow. If the purpose of threads is to allow for
> multitasking and sharing of resources, then why do you have to give a
> thread sleep time in order for other threads to work? Doesn't that
> kind of defeat the purpose?
There are, as has already been pointed out in replies, MANY "purposes
for threads".
The problem in the advice you read is that it makes assumptions that are
not stated -- and which possibly the author did not even understand were
being made because in those days most indigenous Dinosaurian programmers
lived in the environment he describes. It poses extremely narrow and
specialized advice as if it were general. And in fact, in the ancient
time from which he writes, this sort of issue loomed large in the minds
of many programmers... and failing to consider the implications was the
downfall of many. This article may have saved a bunch of readers from,
as the expression goes, "a world of hurt".
BUT, to interpret in a modern context, the article assumes
a) That threaded code runs on the "green" implementations of Java where
a process can execute only on one processor at a time. "Green" threads
refers to an early Java implementation mechanism that built a user-mode
thread scheduler on top of a single kernel execution context. It was a
convenient way to get early Java out into the works, and the same was
originally done for POSIX with "DCE threads"... such implementation
hackery has been obsolete for ages and except in extremely narrow and
specialized areas any such implementation should be viewed with extreme
distrust. There are too many problems and inherent limitations for
general programming.
b) That threaded code can be made to share that single execution stream
only by deliberately designing each thread to block. (Although I might
point out that, given this assumption, it's actually critical that
threads on a "green" thread implementation block in ways that will allow
the user-mode scheduler to recognize the block and schedule another thread.)
> here is my source for the quote.
>
> http://www.javaworld.com/javaworld/jw-04-1996/jw-04-threads.html?page=1
So, it's not so much that the advice here is BAD, though I would never
have put any of it as unconditionally as he did, and even then would
have been using this to warn people away from the unspeakable (however
sometimes necessary and unavoidable) evils of Green threads. But more
than that, in a world where virtually every low-end desktop system is
dual-core, and few Java programmers probably remember the last time they
had to use Green threads (if they even know what it is), it's completely
irrelevant.
It's like opening up an antique reference showing how to avoid a problem
while chipping an arrow head from a block of obsidian that could make
your otherwise perfectly functional arrow head in some subtle fashion
unsuitable for hunting saber tooth tigers. A fascinating glance into an
obscure aspect of history, to be sure; but even if a modern reader were
to want to chip an obsidian arrow head they'd be unlikely to intend to
use it to hunt that particular species.
The difference is that any modern reader understands the age and
technical relevance of obsidian chipping. Whereas if you don't look
carefully at the header, it might seem that the Java article was written
yesterday and was meant to apply to your daily business tomorrow. It
doesn't. I'm sure the author, even writing in a nascent internet age,
never stopped to consider that anyone in 13 years would see a copy, much
less that the reader might be unaware of the age and context.
So let's ignore the Java, because it doesn't matter any more. Let's take
this instead as "Internet 101", and apply it as a cautionary tale when
writing in the Twilight Zone... ;-)
fgu...@gmail.com
Thanks Dave. Yeah, I guess the article is outdated. I find the source,
JavaWorld.com, to be useful though. For they most part, They explain
concepts in a simple and clear manner, when I find that the Sun Java
Tutorial is unnecessarily complicated or advanced. For example, the
concept of a writing a class that extends the Thread class was
presented in a much more easy to understand fashion than at Sun.
Another article I got a lot of mileage out of was one on Animation
applets and threads. Much more straightforward than Sun. Even the
questionable material on sleeptime was made easy to undersatnd, and I
can go back to sun and get a lot more out of their more uptodate, and
advanced, materials.