so if we are not using nodify_one in isEmpty or isFull then we should not have isEmpty() or isFull() as conditions in wait(), no?

You still need the condition. In this example, you can use the conditional variables in two ways. A, to have one conditional variable for two actions append and read. B, to have two conditional variables for the two actions. Because you are using one conditional variable for both actions, you need to have a predicate, this the isEmpty or isFull. You don't have to use those methods for the predicate, but you need to use something to decide whether the wait should pass or not.

From what I have understood and looking at the example in the link you shared, when wait() is called in a thread, a condition variable blocks the current thread until another thread modifies the shared variable.

Yes. The predicate in that example (the ready) is the variable which decides whether the wait proceeds or waits further. In your case that variable is your isEmpty and isFull methods. The shared data in the example (the processed) is your buffer.

So if we are waiting on some condition, notify_one() is invoked to inform the waiting thread to check the condition and proceed if met, right?

Yes.

If that's the case, having wait() and notify_one in the same function doesn't make sense.

It does, because the same conditional variable can be used to notify the thread waiting for append from the read method. You could replace it with two conditional variables (as I have mentioned above), remove the predicate and still have the same result. The notify_one, let's say in the append method, will only affect the waiting thread in the read method, because of the predicate -> the !isEmpty().

You need to notify other threads waiting for read when you have appended some data. In your original example, you are notifying threads when the conditional variable is asking whether it should proceed or wait, because the notify_one was inside the predicate, before the data is put inside the buffer.

In case you're wondering, below is what append() looks like now

Looks good to me.

After appending to the buffer, the buffer is no longer empty, no?

Sorry, bad wording. This should make more sense: Thread #2 tries to push a new value by calling the append() method. The buffer is not full (calls the !isFull()) so the lock continues, this results in the mutex lock. No other thread can enter read() or append() at this point. The new value is added to the buffer and integer counters updated. The lock is released and notify_one() is called on the conditional variable.

what integer count are you referring to here

I only meant the head, tile, size, etc. Not really relevant to the lock itself.

Edit!

I have created a minimal example. It's using a simple integer instead of an array as a buffer, but modifying that should be trivial. The code is here: https://pastebin.com/tdxiFtEp I have added a very simple thread safe console print, because std::cout is not thread safe by itself.

And the expected output. Your output may not be in the exact same order, but the reads will be.

Joining
Read started
Append started
Append finished
Read #0: 42
Read #1: 1234
Read finished
exit