Does Thread::notify() work in advance?


#1

Hello,
I can’t find anything in documentation, but it looks like Thread::notify() works in advance. Am I right?
I mean if Thread is not running, and I call notify(), and then I start thread, then wait(-1) doesn’t wait in the run() on first iteration of while loop.
Is there any way to avoid that? I mean, can I set the notify() just do nothing if thread is not running?

OK, I know I can check like that:

if (myThread.isThreadRunning())
    myThread.notify();

But then I need always check if thread is running? I know when it is running so I don’t want to check it every time. Does it make a sense? Or am I complaining too much?


#2

What answer do you come up with when you read the source code for juce::Thread::notify()?


#3

“Go to definition” takes me to:

void Thread::notify() const
{
    defaultEvent.signal();
}

I am scary when I see defaultEvent, but OK let’s go deeper to signal() definition. It takes me to:

void WaitableEvent::signal() const noexcept
{
    pthread_mutex_lock (&mutex);

    if (! triggered)
    {
        triggered = true;
        pthread_cond_broadcast (&condition);
    }

    pthread_mutex_unlock (&mutex);
}

So now I am killed. I have no idea what is pthread_mutex_lock, as well mutex, and pthread_cond_broadcast, and condition, and pthread_mutex_unlock.

OK I could go deeper for each of that staff. I am pretty sure each one is very interesting, and it would be smart to understand each one.

But you know what? About one year ago I was angry every time I don’t understand something. And I could not go further (some psychologic break) until I don’t understand what’s going on.
I couldn’t do anything because I was always go deep in details.

Then somebody told me: if you want to start programming something, don’t try to understand everything, because it’s just impossible to understand everything. So just take things (methods, classes etc.) like it is. If they work great, if not, use something else.

@matkatmusic Do you understand everything? If not, do you spend week for each small detail to understand until you use it? Great, you are genius and have infinite of time. Congrats.

I didn’t find the answer for my question. But I managed it around. And it works.
:slight_smile:


#4

It’s the only way to actually grow and become a better programmer, so yes. I invested the time so I could become better.

pthread_mutex_lock is a function. the argument passed to it as a MUTEX object. the Mutex is what gets locked.

that line of code is locking the variables used within the scope of that function so they can’t be changed by other functions that are being executed on other threads at the same time.

the if(! triggered) block is sending out a broadcast signal, alerting the condition.

the mutex is unlocked at the end of the function via pthread_mutex_unlock()
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/pthread_mutex_unlock.3.html


#5

Hey thanks for your answer. Actually I still don’t understand anything of it (especially that documentation on apple development), but in some way your answer took me to that signal()
And there is clear answer for my question:
If signal() is called when nothing is waiting, the next thread to call wait() will return immediately and reset the signal.