Andres Valloud <sqrmax at cvtci.com.ar> wrote:
> Now suppose I run a benchmark with the MessageTally on the file system.
> Sure enough, there will be a nice amount of suspend/resumes from
> MessageTally. I would not like MessageTally to make the file system
> crash and burn while it's being tested.
> 

Good example re MessageTally, although even MessageTally could work by
running at a higher priority than the thread in question.  Then the
thread will be guaranteed to be quiet while MessageTally does its work,
without needing the suspend.

Also, MessageTally is anamalous, because you can't reprogram the thread
in question to block itself with semaphores, and because the two threads
in question will never access the same lock.  For most apps, you can
reprogram the thread, and there will actually be locks that both threads
go after that you have to worry about.


For a more eloquent explanation of the situation, people might check out
what Javasoft has to say:

	http://java.sun.com/products/jdk/1.2/docs/guide/misc/threadPrimitiveDep
recation.html


Also, here's what some other random thread package has to say:

(http://www.roguewave.com/products/spmcurrent/thrref/rwthread.html):
>unsigned
>suspend(void)
>throw(RWTHRInvalidPointer, RWTHROperationNotSupported, RWTHRThreadNotActive, RWTHRInternalError);
>
>      Suspends the execution of the thread associated with self until a matching resume() operation is performed.
>      Caution: Use of this function may produce unexpected deadlock (see the User's Guide for more information).
>      For deadlock-safe suspension use requestInterrupt() and serviceInterrupt() instead. 

>      At run-time use canSuspendResume() to determine the availability of this feature. At compile-time check to
>      see if RW_THR_HAS_SUSPEND_RESUME is defined.




It looks like everyone intuitively adds suspend() and kill() calls when
they first create a thread package, and then about half of them end up
arguing that you shouldn't use them.

Lex