Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • Home
  • SEARCH
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 845847
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 15, 20262026-05-15T06:31:14+00:00 2026-05-15T06:31:14+00:00

I’m writing a latency sensitive app that in effect wants to wait on multiple

  • 0

I’m writing a latency sensitive app that in effect wants to wait on multiple condition variables at once. I’ve read before of several ways to get this functionality on Linux (apparently this is builtin on Windows), but none of them seem suitable for my app. The methods I know of are:

  1. Have one thread wait on each of the condition variables you want to wait on, which when woken will signal a single condition variable which you wait on instead.

  2. Cycling through multiple condition variables with a timed wait.

  3. Writing dummy bytes to files or pipes instead, and polling on those.

#1 & #2 are unsuitable because they cause unnecessary sleeping. With #1, you have to wait for the dummy thread to wake up, then signal the real thread, then for the real thread to wake up, instead of the real thread just waking up to begin with — the extra scheduler quantum spent on this actually matters for my app, and I’d prefer not to have to use a full fledged RTOS. #2 is even worse, you potentially spend N * timeout time asleep, or your timeout will be 0 in which case you never sleep (endlessly burning CPU and starving other threads is also bad).

For #3, pipes are problematic because if the thread being ‘signaled’ is busy or even crashes (I’m in fact dealing with separate process rather than threads — the mutexes and conditions would be stored in shared memory), then the writing thread will be stuck because the pipe’s buffer will be full, as will any other clients. Files are problematic because you’d be growing it endlessly the longer the app ran.

Is there a better way to do this? Curious for answers appropriate for Solaris as well.

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-15T06:31:15+00:00Added an answer on May 15, 2026 at 6:31 am

    If you are talking about POSIX threads I’d recommend to use single condition variable and number of event flags or something alike. The idea is to use peer condvar mutex to guard event notifications. You anyway need to check for event after cond_wait() exit. Here is my old enough code to illustrate this from my training (yes, I checked that it runs, but please note it was prepared some time ago and in a hurry for newcomers).

    #include <pthread.h>
    #include <stdio.h>
    #include <unistd.h>
    
    static pthread_cond_t var;
    static pthread_mutex_t mtx;
    
    unsigned event_flags = 0;
    #define FLAG_EVENT_1    1
    #define FLAG_EVENT_2    2
    
    void signal_1()
    {
        pthread_mutex_lock(&mtx);
        event_flags |= FLAG_EVENT_1;
        pthread_cond_signal(&var);
        pthread_mutex_unlock(&mtx);
    }
    
    void signal_2()
    {
        pthread_mutex_lock(&mtx);
        event_flags |= FLAG_EVENT_2;
        pthread_cond_signal(&var);
        pthread_mutex_unlock(&mtx);
    }
    
    void* handler(void*)
    {
        // Mutex is unlocked only when we wait or process received events.
        pthread_mutex_lock(&mtx);
    
        // Here should be race-condition prevention in real code.
    
        while(1)
        {
            if (event_flags)
            {
                unsigned copy = event_flags;
    
                // We unlock mutex while we are processing received events.
                pthread_mutex_unlock(&mtx);
    
                if (copy & FLAG_EVENT_1)
                {
                    printf("EVENT 1\n");
                    copy ^= FLAG_EVENT_1;
                }
    
                if (copy & FLAG_EVENT_2)
                {
                    printf("EVENT 2\n");
                    copy ^= FLAG_EVENT_2;
    
                    // And let EVENT 2 to be 'quit' signal.
                    // In this case for consistency we break with locked mutex.
                    pthread_mutex_lock(&mtx);
                    break;
                }
    
                // Note we should have mutex locked at the iteration end.
                pthread_mutex_lock(&mtx);
            }
            else
            {
                // Mutex is locked. It is unlocked while we are waiting.
                pthread_cond_wait(&var, &mtx);
                // Mutex is locked.
            }
        }
    
        // ... as we are dying.
        pthread_mutex_unlock(&mtx);
    }
    
    int main()
    {
        pthread_mutex_init(&mtx, NULL);
        pthread_cond_init(&var, NULL);
    
        pthread_t id;
        pthread_create(&id, NULL, handler, NULL);
        sleep(1);
    
        signal_1();
        sleep(1);
        signal_1();
        sleep(1);
        signal_2();
        sleep(1);
    
        pthread_join(id, NULL);
        return 0;
    }
    
    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

No related questions found

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.