Suspension of Linux threads.
David
Is there a way to suspend the execution of a thread from another thread?
Under Windows, I know of a function called "SuspendThread(threadID).
However, I have not seen any such function in Linux. I have tried searching
the man pages but to no avail.
Thanks,
David
Kaz Kylheku
>Hi,
>
>Is there a way to suspend the execution of a thread from another thread?
>Under Windows, I know of a function called "SuspendThread(threadID).
Yes, but only idiots use it. (As well as maybe a few people who write debuggers
or multithreaded garbage collectors).
Suspending one thread from another might as well be called
InsertStandardMicrosoftRaceConditionHereExExEx();
It can only be done if you are willing to inspect the entire
machine-specific state of that thread to find out what it was doing.
For example, a garbage collector might suspend all threads and then
examine all of their registers to find pointers to any live objects.
David
down to the details of machine state and etc.. Just want to maybe use
signals or function to suspend a thread from another thread and then
resuming the thread from another thread.
Thanks,
David
"Kaz Kylheku" <k...@accton.shaw.ca> wrote in message
news:_ai28.16340$Sg7.8...@news1.calgary.shaw.ca...
Kaz Kylheku
>Is there a function or an easier way to achieve that? I don't want to go
>down to the details of machine state and etc.. Just want to maybe use
>signals or function to suspend a thread from another thread and then
>resuming the thread from another thread.
If you don't know what the suspended thread was doing when you suspended
it, how can you ensure that your program is correct?
What actual problem are you trying to solve?
In other words, how does thread suspending trace back to a functional
requirement for the software you are trying to write?
David Schwartz
> Is there a function or an easier way to achieve that? I don't want to go
> down to the details of machine state and etc.. Just want to maybe use
> signals or function to suspend a thread from another thread and then
> resuming the thread from another thread.
What is your actual requirements? Why do you think you want to suspend
a thread?
DS
David
I have sort of found the answer to my problem just recently from a fren but
he advised me on the many dangers of suspending a thread under Linux. So I
decided to drop the idea altogether. I guess it is necessary to implement
things in "the hard way". Anyway, what I wanted to suspend was a thread that
does a disk scan, upon completing, waits for a specified interval of time
and does a disk scan again...going around in a loop. The user can disable
the scanning loop and so I wanted to wait for the disk scan to complete and
then suspend the thread upon entering into the sleeping phase.
"David Schwartz" <dav...@webmaster.com> wrote in message
news:3C4B48A6...@webmaster.com...
Alexander Terekhov
Apropos garbage collector/"Under Windows, I know of a function
called "SuspendThread(threadID)".
Does anyone have an idea how it is supposed to work
not breaking MS-event-based synchronization, given:
http://support.microsoft.com/support/kb/articles/Q173/2/60.ASP
Is anyone already doing MT-stuff under MS.Net?
regards,
alexander.
David Schwartz
> I have sort of found the answer to my problem just recently from a fren but
> he advised me on the many dangers of suspending a thread under Linux. So I
> decided to drop the idea altogether. I guess it is necessary to implement
> things in "the hard way". Anyway, what I wanted to suspend was a thread that
> does a disk scan, upon completing, waits for a specified interval of time
> and does a disk scan again...going around in a loop. The user can disable
> the scanning loop and so I wanted to wait for the disk scan to complete and
> then suspend the thread upon entering into the sleeping phase.
So why not just have a 'suspend' variable protected by a mutex. The
scanning thread simply checks the value of the variable before it starts
another scan. Suspending the thread is most definitely the hard way!
DS
David
by the user during the midst of a scan also. At the same time, I do not want
to lose any memory allocated (ie memory leaks) by killing off the thread.
Besides, the idea of re-creating the thread everytime the user disables the
scan doesn't appeal to me. (since this disabling of the scan can also be
initiated by the program itself and can be quite frequent.)
"David Schwartz" <dav...@webmaster.com> wrote in message
news:3C4C4E3F...@webmaster.com...
Steve Watt
David <tea...@singnet.com.sg> wrote:
[ top-posting fixed ]
>"David Schwartz" <dav...@webmaster.com> wrote in message
>news:3C4C4E3F...@webmaster.com...
>> David wrote:
>> > I have sort of found the answer to my problem just recently from a fren but
>> > he advised me on the many dangers of suspending a thread under Linux. So I
>> > decided to drop the idea altogether. I guess it is necessary to implement
>> > things in "the hard way".
It's not the hard way, believe me. If you've ever tried to debug a program
that used a thread-suspend call for an attempt at synchronization, you'd
know that doing it correctly (without a suspend call) is *NOT* the hard way.
>> > [...] Anyway, what I wanted to suspend was a thread that [...]
>>
>> So why not just have a 'suspend' variable protected by a mutex. The
>> scanning thread simply checks the value of the variable before it starts
>> another scan. Suspending the thread is most definitely the hard way!
>
>Well, that would have been easy indeed. But I wanted the scan to be stopable
>by the user during the midst of a scan also. At the same time, I do not want
>to lose any memory allocated (ie memory leaks) by killing off the thread.
>Besides, the idea of re-creating the thread everytime the user disables the
>scan doesn't appeal to me. (since this disabling of the scan can also be
>initiated by the program itself and can be quite frequent.)
If you correctly use cancellation cleanup handlers, you won't get
memory leaks.
The fundamental flaw in a remote suspend function is that you have no
idea what the thread you're about to suspend is doing at that precise
instant. It could be down in, say, malloc() (or new), and have the
entire heap locked. If any other thread then needs to get some heap
space, it would have to wait for the thread to be resumed. I hope the
thread that needed the heap space isn't the one that called suspend.
If you know to a precise enough level of detail what the thread is
doing when you want to suspend it, have it check a running flag there.
It gives you *much* better control over where/when the thread gets
stopped, so you can understand the full consequences.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
Alexander Terekhov
Steve Watt wrote:
[...]
> The fundamental flaw in a remote suspend function is that you have no
> idea what the thread you're about to suspend is doing at that precise
> instant. It could be down in, say, malloc() (or new), and have the
> entire heap locked. If any other thread then needs to get some heap
> space, it would have to wait for the thread to be resumed. I hope the
> thread that needed the heap space isn't the one that called suspend.
A similar problem "exists" with respect to fork().
In no way you should think of me as a friend of
async.suspend, but I do think, however, that a
*deadlock-free* async.suspend COULD be implemented
using existing mechanism of pthread_atfork() PREPARE
and PARENT handlers, which perhaps being terribly
slow, nevertheless might be useful in a *very*
limited number of applications. Oder?
regards,
alexander.
David Schwartz
> Well, that would have been easy indeed. But I wanted the scan to be stopable
> by the user during the midst of a scan also. At the same time, I do not want
> to lose any memory allocated (ie memory leaks) by killing off the thread.
> Besides, the idea of re-creating the thread everytime the user disables the
> scan doesn't appeal to me. (since this disabling of the scan can also be
> initiated by the program itself and can be quite frequent.)
So have the thread that's doing the scan check to see if it should stop
at reasonable intervals. I'd create a mutex, a condition variable, and a
predicate integer. For the predicate integer, 1 can mean stop and 0 can
mean go.
To stop the scanning thread, lock the mutex, set the predicate to '1',
unlock the mutex, and signal the condition variable. Every once in a
while, have the scanning thread lock the mutex, block on the condition
variable while the predicate is not '0', and then unlock the mutex.
DS
crux
I'm afraid there is such a way to achieve it in Linux too.
If you read the info documentation on pthread (glibc add-on) you'll find
that LinuxThread implementation depart from POSIX because outer signal to
a thread is delivered only to the thread, not all the process.
Now, if you send a kill to the pid of a particular thread you can surely
1.SIGKILL
2.SIGSTOP
3.SIGCONT
There are no point to do this from inside the main process, and calling
it a thread function is not correct, but if you are writing a debugger
you know how to do it. Anyway you can use getpid to store the pid of every
thread and kill'em.
Kaz Kylheku
crux wrote:
>On Sat, 19 Jan 2002 18:27:20 +0100, David wrote:
>
>> Hi,
>>
>> Is there a way to suspend the execution of a thread from another thread?
>> Under Windows, I know of a function called "SuspendThread(threadID).
>> However, I have not seen any such function in Linux. I have tried
>> searching the man pages but to no avail.
>
>I'm afraid there is such a way to achieve it in Linux too.
>
>If you read the info documentation on pthread (glibc add-on) you'll find
>that LinuxThread implementation depart from POSIX because outer signal to
>a thread is delivered only to the thread, not all the process.
>
>Now, if you send a kill to the pid of a particular thread you can surely
>
>1.SIGKILL
>2.SIGSTOP
>3.SIGCONT
The problem with this,a gain, is that you don't know what the thread
is doing when you kill it rudely like this or pause it. It may be
currently holding a lock, such as perhaps some internal lock within
libc. The effect will be that other threads will block. when they try
to acquire the lock and your whole application may hang.
Steve Watt
Alexander Terekhov <tere...@web.de> wrote:
>
>Steve Watt wrote:
>[...]
>> The fundamental flaw in a remote suspend function is that you have no
>> idea what the thread you're about to suspend is doing at that precise
>> instant. It could be down in, say, malloc() (or new), and have the
>> entire heap locked. If any other thread then needs to get some heap
>> space, it would have to wait for the thread to be resumed. I hope the
>> thread that needed the heap space isn't the one that called suspend.
>
>A similar problem "exists" with respect to fork().
And, one might argue, wasn't quite solved completely. There are some
"interesting" problems with atfork handlers, most of them having to do
with the fact that fork() is legal inside a signal handler[1].
>In no way you should think of me as a friend of
>async.suspend, but I do think, however, that a
>*deadlock-free* async.suspend COULD be implemented
>using existing mechanism of pthread_atfork() PREPARE
>and PARENT handlers, which perhaps being terribly
>slow, nevertheless might be useful in a *very*
>limited number of applications. Oder?
Except that then you need to have some mechanism for the thread calling
suspend to block until the prepare handlers have all completed. Since
the only legit use I have seen for suspend/resume is a debugger (OK,
and garbage collection, but I'm mostly a C guy), having a whole bunch
of extra code run is undesirable. Besides, you'd then have the extra
overhead of each resource-collecting function in the system having
to register suspend handlers... Probably not worth the cost for the
extremely minimal return.
[1] I understand the legacy code reasons for this decision, but I still
view it as probably the single worst bug in the POSIX standards.
crux
I agree.
Under Windows there is SuspendThread(threadID) function because there is
no fork() and to create a process you have to install a thread, irrc.
All that make concepts confused, either windows system call and LinuxThread
implementation
Alexander Terekhov
[...]
> Under Windows there is SuspendThread(threadID) function because there is
> no fork() and to create a process you have to install a thread, irrc.
No. CreateProcess aside, the real reason why there is
"SuspendThread(threadID) function" is that for MS
company the marketing/profit is above the interests
of their customers and high quality engineering!
For example, I am still awaiting for "official"/any
response with respect to:
http://sources.redhat.com/ml/pthreads-win32/2001/msg00158.html
In the meantime, MSDN site continues to
FOOLISH/FRUSTRATE zillions of innocent
programmers. That is BAD!
(Disclaimer: working for IBM Germany; my own opinions;
and in no way reflect official opinion or
policy of IBM Corp)
regards,
alexander.
crux
> crux <cr...@nowhere.wherenoexist.it> wrote in message
>> Under Windows there is SuspendThread(threadID) function because there
>> is no fork() and to create a process you have to install a thread,
>> irrc.
^^^^
aims to be iirc, and actually idnrc
I've read
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndllpro/html/msdn_metrsect.asp
I'm concerned about the table:
Name Relative speed Cross process Resource counting
Critical Section Fast No No (Exclusive Access) 95/NT/CE
Mutex Slow Yes No (Exclusive Access) 95/NT/CE
Semaphore Slow Yes Yes 95/NT
Event Slow Yes Yes* 95/NT/CE
Metered Section Fast Yes Yes 95/NT/CE
Now Critical Section can do what does POSIX semaphore and mutex. But what
about POSIX signals? Also (as far i don't need windows) where does it is a
similar table for POSIX sync functions? (performance in LinuxThread)
anyway, thank you for the enlightenment on MS concepts and function.
Norman Black
Signals are a Unix thing. Windows has no equivalent. I have seen many,
in this and other groups, recommend avoid using signals in a threaded
app.
> where does it is a similar table for POSIX sync functions?
The relative speed for Win32 sync objects is in reference to if it is a
kernel object. Meaning a kernel transition must always be done even when
there is no contention. Most all POSIX threading libraries (including
Linux) are pure user mode. A kernel transition only occurs when a thread
is blocked. As for cross process support, the Linux pthreads library
provides little support for this (any objects support inter-process?).
--
Norman Black
Stony Brook Software
nospam => stonybrk
"crux" <cr...@nowhere.wherenoexist.it> wrote in message
news:pan.2002.01.24.18...@nowhere.wherenoexist.it...
Charles Bryant
Norman Black <nos...@ix.netcom.com> wrote:
>> But what about POSIX signals?
>
>Signals are a Unix thing. Windows has no equivalent. I have seen many,
>in this and other groups, recommend avoid using signals in a threaded
>app.
Actually, Windows does have something which is like signals. By
using an APC (Asynchronous Procedure Call) a thread can be made to
execute code like a signal handler. However it's just as inadviseable
to mess about with APCs in multithreaded code as it is to use signals
on Unix.
--
Eppur si muove
David Schwartz
> Actually, Windows does have something which is like signals. By
> using an APC (Asynchronous Procedure Call) a thread can be made to
> execute code like a signal handler. However it's just as inadviseable
> to mess about with APCs in multithreaded code as it is to use signals
> on Unix.
Since APCs never interrupt code while it's running but only get
executed when the thread is waiting (and 'altertable' as well), there's
really no reason to avoid them. The only argument against using them is
the completion ports are better.
DS
Alexander Terekhov
>
> Charles Bryant wrote:
>
> > Actually, Windows does have something which is like signals. By
> > using an APC (Asynchronous Procedure Call) a thread can be made to
> > execute code like a signal handler. However it's just as inadviseable
> > to mess about with APCs in multithreaded code as it is to use signals
> > on Unix.
>
> Since APCs never interrupt code while it's running but only get
> executed when the thread is waiting (and 'altertable' as well),
Yep; but I guess that something along the lines
of pthreads-win32's async-cancel[1] could be used
to "emulate" signals (not that I really see any
reasons to do this ;-)
> there's
> really no reason to avoid them. The only argument against using them is
> the completion ports are better.
Are there any chances to have something like
this (i.e. MS-style "completion ports" thread-
pooling[2] or even something better ;-) in some
future Pthreads? Perhaps Mr.Butenhof and a like
(I mean "real" Pthread-implementors/Austin Group
working group members/technical reviewers folks)
could elaborate... please!
regards,
alexander.
[2]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndllpro/html/msdn_scalabil.asp