If this is Java, first have a good long look at java.util.concurrent. Trying to reinvent what was already solved creates so many subtle problems. It seems simple, but it's incredibly hard to get it just right.
Be careful to think about what you are doing. You seem to be asking for one thread to produce data, and the other thread to consume data. You don't want to block, so you have no choice but to make the second thread repeatedly poll. There are all sorts of established design patterns for this. Ask yourself: (1) does the first thread produce a boolean "event" (like "it happened"); (2) will the event have to get reset and occur again; (3) will you combine the event with data (like a boolean plus a string); and so forth. Each of these considerations adds complexity for synchronization between threads.
A common flaw for (3) above, is a synchronized method or mutex block to ask "is there data", then unblock, then the 2nd thread thinks it now wants the data, and asks "give me that data". In between the "is there data" and "give me that data", the first thread can reset the state to no event present and reset the data to nothing. The second thread is now asking for something that doesn't exist.
Rather than hunt down all these subtle interactions, look to reuse a design pattern and use a well-established concurrent utility.