Member Avatar for vedro-compota

Hello everyone))

Guys please tell me - is there any way to create thread in lunux , which will not executed itself (at all) - until will get SIGCONT signal?

I can't thread self stopping after creation , because in this case - we cann't be sure that the thread will be stopped exactly before (not after) parent process will send SIGCONT to it - that's possible that the thread will be find in not active state after getting SIGCONT from another one (because of multithreading)

So I need to be sure that the thread has been stoped by the moment the other thread send the SIGCONT to the first one.

If someone know - how to do this - please help.

big thanks in advance))

  • 4 Contributors
  • 10 Replies
  • 408 Views
  • 1 Month Discussion Span
  • Latest Post Latest Post by vedro-compota

Dani AI

Generated

Short answer for : using job-control signals (SIGSTOP / SIGCONT) to pause a single pthread isn’t workable — SIGSTOP/SIGCONT act on the whole process and SIGSTOP/SIGKILL cannot be caught or ignored. pthreads do inherit the creating thread’s signal mask, but that alone doesn’t give you a safe “create‑stopped” thread mechanism for per‑thread start/continue semantics. (man7.org)

A simpler, robust solution is to synchronize thread start explicitly with pthread primitives (mutexes/condition variables or semaphores). As pointed out, a locked mutex can block a new thread; a condition variable gives a clearer intent when you want “start when both readers are done.” Example pattern:

/* comparator thread */
pthread_mutex_lock(&m);
while (!ready) pthread_cond_wait(&cv, &m);
pthread_mutex_unlock(&m);
/* do compare / print */

Main thread sets ready = 1; pthread_cond_signal(&cv); after both readers finish. Use a separate mutex for console output (or write to stderr and fflush) to avoid interleaved printing. See pthread_cond_wait documentation for the correct wait/signal idiom. (man7.org)

If signals are mandatory, use the POSIX pattern to avoid races: block the relevant signals in the creating thread, create the threads (they inherit the blocked mask), have threads set their own masks as needed, then restore the creator’s mask — or block signals everywhere and run one dedicated signal‑handler thread that calls sigwait() and then notifies other threads (via condvar/queue). That eliminates the race of “thread running before you intended.” See the pthread signal‑mask and sigwait recommendations for details. (man7.org)

Recommended: prefer mutex+condvar or a semaphore for ordering and console serialization; use signals only for true asynchronous events and follow the sigwait/block pattern if you must.

Recommended Answers

All 10 Replies

Member Avatar for nezachem

I don't think it is possible. What exactly are you trying to achieve? I mean, is using signals a requirement?

commented: +++++++++++ +3
Member Avatar for vedro-compota

your intuition is good)
I would like to use signals .
Yes - to be concrete - for example - i have 3 threads (list) =
1) the first one reads first txt file into memory
2) the second reads second txt file into memory
3) and the third thread compare each other arrays , which had been made by the previous two threads

I need perform all operations in such order as in list , because all of them(threads)))) use console to show some notifications about own work.

In the general case this situation needs that at least the third thread will be stoped just after creation.

Member Avatar for nezachem

I need perform all operations in such order as in list

This sort of defeats the purpose of multithreading...

this situation needs that at least the third thread will be stoped just after creation

A semaphore or a conditional variable would do it much better.

Member Avatar for vedro-compota

This sort of defeats the purpose of multithreading...

yes - you're right - but what about this -

this situation needs that at least the third thread will be stoped just after creation

you said =

A semaphore or a conditional variable would do it much better.

so - there's no way to stop comparision thread safety using signals ?

Member Avatar for vedro-compota

in windows there's WaitForMultipleObjects () function - it can solve this problem, but in linux....can't))

Member Avatar for nezachem

so - there's no way to stop comparison thread safely using signals ?

No. The pthread_create man page explicitly says that
The set of pending signals for the new thread is empty

Member Avatar for robea

I can definitely help you, if your problem is related to windows. Thread safety is the most important part of software development. You can find thread safety related to windows .net development here . Its an important part of development and helps to create real time trading applications

Edited by robea because: n/a
Member Avatar for vedro-compota

thank you robea but my problem is related to Linux)

Member Avatar for L7Sqr

You can do this directly with a mutex. It is not a signal, but is more suited to synchronizing threads. Example:

pthread_mutex_t the_lock = PTHREAD_MUTEX_INITIALIZER;

void * thread_fun(void * ignore) {
    struct timeval tv;
    pthread_mutex_lock (&the_lock);
    gettimeofday (&tv, NULL);
    fprintf(stderr, "thread: %d.%06d\n", tv.tv_sec, tv.tv_usec);
    return NULL;
}

int main () {

    pthread_t thr;
    struct timeval tv;

    /* lock the mutex *before* creating the thread */
    pthread_mutex_lock (&the_lock);
    pthread_create (&thr, NULL, thread_fun, NULL);
    fprintf (stderr, "main snoozing for a bit...\n");
    sleep (2);
    gettimeofday (&tv, NULL);
    fprintf(stderr, "main: %d.%06d\n", tv.tv_sec, tv.tv_usec);

    /* Unlock and wait for thread */
    pthread_mutex_unlock (&the_lock);
    pthread_join (thr, NULL);
    return 0;
}

In that example, the thread will not execute beyond the lock request until the calling thread releases the lock on the mutex.

commented: ++++++++++++ +3
Member Avatar for vedro-compota

thank you L7Sqr )

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.