Jump to content
  • Advertisement
Sign in to follow this  
Finalspace

POSIX thread resume and suspend

Recommended Posts

I am implementing POSIX threading in my library but havent found any function for suspending or resuming a pthread_t. From my research it seems that there is no "suspend" or "resume" ability at all. Does linux not support any suspend/resume operations on threads?

So the only way to get suspend/resume you have to implement it yourself using some sort of locking, signaling mechanism - including some callback to the user to check for suspend...??

Edited by Finalspace

Share this post


Link to post
Share on other sites
Advertisement

First, if you target C++11, then simply use std threads.

For about pthreads, conditions are certainly what you want.

A quick search on google about 'pthread suspend' gave me this; https://www.google.fr/search?source=hp&ei=_M1xWpfNL8fLwAK49rfQCQ&q=pthread+suspend&oq=pthread+suspend&gs_l=psy-ab.3..0i19k1l3j0i22i30i19k1l7.561.3272.0.3408.15.14.0.1.1.0.222.1736.3j5j3.11.0....0...1c.1.64.psy-ab..3.12.1742...0j0i131k1j0i10k1j0i22i30k1.0.pEJ0VIlpYtk

Share this post


Link to post
Share on other sites

Seems it was there in Solaris, but not in Linux:

https://www.ibm.com/developerworks/systems/articles/porting_linux/

Quote

Note: The POSIX standard provides no mechanism by which a thread, A, can suspend the execution of another thread, B, without cooperation from thread B. The only way to implement the suspend or restart mechanism is to have thread B periodically check some global variable for a suspend request and then suspend itself on a condition variable, which another thread can signal later to restart B.

 

Share this post


Link to post
Share on other sites

There is a reason that suspend and resume do not exist in posix and many others, they are inherently unsafe.  Because you don't know exactly where the thread will be during a suspend there are a lot of different things which could go wrong.  For instance, if you suspend with a lock under the threads control, this can cause a very difficult to find/understand deadlock.  For this reason it was deemed best to avoid this and make programmers use explicit synchronization.  In general this is the best solution even if the API's are available because you know the exact state at the point of suspension, i.e. I suggest not supporting this even on Window's.  See the caution here: https://msdn.microsoft.com/en-us/library/system.threading.thread.suspend(v=vs.110).aspx, and the fact that it is deprecated in .Net moving forward for these and other reasons.

Share this post


Link to post
Share on other sites

I came accross this some time ago too but dont need it that much. My solution was/is looking into micro-tasking using fibers so you could swap context at any time during execution (what is the same as suspending/resuming a thread while you potentially have no scheduling delay between them). The drawbacks are that this needs to be done with a little assembly code for every platform/target set you need it to work on (windows+x86, windows+x64, unix+x86, unix+x64, unix+arm ...)

It also pointed out that running a larger number of threads with some locking and signaling mechanism is much more efficient in posix then it is in windows and there exists some suspend/resume workarrounds (i have not tested yet)

pthread_mutex_t mutex;
static void thread_control_handler(int n, siginfo_t* siginfo, void* sigcontext) {
    // wait time out
    pthread_mutex_lock(&mutex);
    pthread_mutex_unlock(&mutex);
}
// suspend a thread for some time
void thread_suspend(int tid, int time) {
    struct sigaction act;
    struct sigaction oact;
    memset(&act, 0, sizeof(act));
    act.sa_sigaction = thread_control_handler;
    act.sa_flags = SA_RESTART | SA_SIGINFO | SA_ONSTACK;
    sigemptyset(&act.sa_mask);
    pthread_mutex_init(&mutex, 0);
    if (!sigaction(SIGURG, &act, &oact)) {
        pthread_mutex_lock(&mutex);
        kill(tid, SIGURG);
        sleep(time);
        pthread_mutex_unlock(&mutex);
    }
}

(Source:StackOverflow)

Share this post


Link to post
Share on other sites

I see, so i will clearly not implement suspend or resume in any POSIX systems at all - just returning false for Suspend and Resume calls. Also i wont allow creation of threads which should be suspended at startup in POSIX too.

21 hours ago, All8Up said:

I suggest not supporting this even on Window's.  See the caution here: https://msdn.microsoft.com/en-us/library/system.threading.thread.suspend(v=vs.110).aspx, and the fact that it is deprecated in .Net moving forward for these and other reasons.

This is new for me - thanks for letting me know!. But right now SuspendThread() und ResumeThread() in win32 works just fine, so i leave it like that.

 

Regarding the discussion about suspend being evil: I agree, the caller should use proper mechanism to syncronize stuff and make the thread exitable at any time - without relying on suspend/resume.

Edited by Finalspace

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!