Subj : Re: Windows Suspend/ResumeThread API equivalent for Linux or POSIX?
To   : comp.programming.threads
From : Oliver S.
Date : Thu May 12 2005 05:57 am

> Here is a paper describing the original SMR algorithm:
> http://www.research.ibm.com/people/m/michael/ieeetpds-2004.pdf

I have this paper already on my computer, but I haven't got the
time to study it.

> Yes, I believe it used SEH to handle the problems with freeing
> it's nodes?

Yes, you remember right. And it's really exiting to see how this
simple trick perfectly circumvents the deallocation-problem. This
originates in one of my bathtub-ideas *G*.

> For this tweaked version of SMR I need to suspend the threads in
> order to get a snapshot of there current context, at least on win-
> dows.

It's a smart idea, but I think David is right wehen he objects,
that this is very costly. And beyond that, it's absolutely unpor-
table, even between different Unices (if they'd support the thread
-inspection APIs) because on every different architecture you to
regard different registers to inspect the current instruction-poin-
ter and state-registers.

>> So isn't it possible that this suspension statistically needs
>> a very small amount of computation-time because it is done very
>> rare ?

> Yes. About every five seconds for read-mostly collections. 

I don't know whether you understood me correctly: I wanted to ask
you if this thread-suspension is done only done in case of a col-
lision between two threads being in a race-condition for a certain
point in time and in most cases this collision doesn't happen so
that this threads-suspension accounts to the *average* effort to
access that shared resource only very slightly.

.