Subj : Re: Windows Suspend/ResumeThread API equivalent for Linux or POSIX?
To   : comp.programming.threads
From : Chris Thomasson
Date : Thu May 12 2005 12:58 am

>> 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*.

:)




> 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.

Yeah. I am only tinkering around with this because I need to build a list of 
different ways to implement SMR in user-space. I need this list so I can 
compare and contrast each method against an ( unpublished ) algorithm I 
created.




> 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.

No. I need access to thread context only in the polling phase of this 
particular modified SMR algorithm.

.