Discard the notion of calling them “booleans.”   They are Work Items, which periodically change state.   And, for each one of these, there is a “cloud” of Interested Parties out there which are waiting for them to become what they are now not.   Those same Interested Parties also need to know when any Work Item ceases to be as it is now.

So, when we introduce a new Interested Party, we associate with it a hash containing, for each Work Item, its last known state.   The Interested Party also contains a count (>= 0) of the number of Work Items it is waiting-upon to change state.   Each Work Item has a list of all of the Interested Parties who are now watching it.

When a Work Item changes state, it notifies all of the Interested Parties, providing its unique-ID and new state.   The Interested Party retrieves the last known state and determines if it has changed.   The appropriate action is determined by an easy four-row state table:

New State	Last State	Action
True	True	Take no action.
True	False	Signaled: update last-known-state, decrement wait count. If zero, remove yourself from all interested-parties lists and destroy yourself. (If negative, die!)
False	False	Take no action.
False	True	Unsignaled: update last-known-state, increment wait count.

You have now completely eliminated the problem of “searching” for anything.

Please notice that I stipulated that Work Items contain a list of references to Interested Parties, but that they provide the parties a unique-id.   This somewhat arbitrary arrangement avoids circular references which can cause headaches for a garbage collector.