“I guess I was thinking he was looking for some sort of callback when the data was ready to be transferred. What Joe suggests is perfectly reasonable solution for simply transferring at any time without an event.”
@ Stephen. It depends on what your doing. Keep in mind that events/callbacks are running in the context of the event source. So that may not be what your after in terms of concurrency. What you described was the consumer/producer pattern, not the event pattern. Either way, you will likely need a lock to protect shared object(s). A lock, as Joe describes, is exactly what we are doing with a shared queue. If you are just sharing an object, it is same concept. Say, for example, it was just a shared string or Int. You need some way to signal other thread when the state changes. How would consumer thread know when data has changed? How would producer know when it was safe to overwrite the value with a new value? You could ping-pong on wait event, but then both threads are blocking again and not doing work and may as well single thead the whole thing. The queue solves that particular issue via buffering which frees both threads to do their own thing and only lock for very short time on queue add/take operations.
P.S. Foklore warning. These patterns developed many moons ago by the long-hairs.