No. There is already a "real" reason for the notification ("a
condition"), and it should be set by the notifying thread before
notify() is called, within the synchronized block:

 synchronized (someObject) {
   setCondition(true);
   someObject.notify();
 }

The waiting thread *must* test for that condition before calling
wait() in every case. This is sufficient to avoid problems caused by
calling notify() prior to wait():

 synchronized (someObject) {
   while (!getCondition()) { /* until the condition becomes true */
     someObject.wait();
   }
 }
 
Adding an additional, artifical condition (notifyCalled) gains you
nothing and in fact only distracts from the real condition that is
being communicated between the threads. Understand too the distinction
between a condition stated in terms of the problem domain (e.g. "data
is ready"), and in terms of the implementation ("notify was called").
The latter of these indicates poor design IMO.

The loop is necessary in the case of spurious interrupts, but it also
lets multiple waiting threads contend on a single lock when
notifyAll() is used (and in this case, the condition should likely be
"cleared" by the first waiting thread that discovers the condition).

/gordon