Would anyone object to a simple, basic thread question? No problem at all. This is a good forum for it.
However I think the answer to this question really depends on how we define various possible thread states. I don't have a copy of Hyde's book, so I don't know how he defines them. The JLS and JVM spec do not define names for thread states (not the ones we're talking about here anyway), so there's really no single official definition. Sun's Java tutorial does have some discussion
here. If we use these definitions of "Runnable" and "Not Runnable" (which are unrelated to the Runnable interface) then a thread which is attempting to acquire a lock on a monitor (attempting to enter a sync block) remains "Runnable" the whole time - even if it can't proceed because some other thread is holding the lock. We avoid using the term "wait" for this process because that is used exclusively for what happens when a thread invokes the wait() method - which is a different thing than merely contending for a lock. Note that according to the tutorial definition, wait() does cause a thread to enter the "Not Runnable" state, but contending for a lock does not.
Unfortunately the tutorial does a poor job here of explaining exactly what happens during lock contention. The fact that they didn't bother to present a term for this process is a cause for confusion. And saying that a thread which is trying to acquire a lock is "Runnable" is mesleading at best, since the thread may even be daedlocked at this point. So some authors (Paul Hyde is probably one) have introduced their own additional terms to discuss these subtleties. My old copy of RHE refers to a "seeking lock" state, as well as "ready" and "running" - these are all within the "Runnable" defined by the tutorial. To me, the RHE terms are much more useful - but they're not necessarily standard. Whatever Paul Hyde is using is probably something similar. (Except I see he's used "wait" in a non-wait() context, so I'd be a bit suspicious that his terminology my be misleading.)
Anyway, as Dana correctly observes, the actual implementation behind this stuff is probably smarter than some of the explanations make it sound. It wouldn't surprise me at all if only one thread actually changes state when a lock becomes available. But this is beyond the level of what we can reliably talk about in general - different JVM implementations can do whatever they want here. What matters is that only one thread that syncs on a given monitor will actually be able to run, until the sync block is completed and another thread can have a go at it. Details beyond this are up to JVM implementors.