A bit of a disclaimer first: I don't know really what your problem is (For example if I fully understood it, the best answer might be to rearchitect) and second I am a self-taught async architect so there are probably gaps in my logic others may be more capable of helping with. Thirdly, I'm a .NET developer so you'll have to translate my suggestions to whatever language you deem needed.
That said, I think an "easy" solution to the problem you described is for your producer to set a magic variable "isDone==true;" when it's finished. The consumer can spin if it waits for too long, and during the spin it can check the value of .isDone. and if isDone==true, it knows it should consume all remaining input, ignoring your "required buffer"
Another potential solution is for your consumer to consume as fast as possible, but setup your "sub-packets" in a way so that the consumer can identify if a packet is incomplete, and not actually "process" the sub-packets until it gets everything needed.
Another suggestion would be to make each enqueue atomic, and not split your packets so the consumer doesnt have the additional complexity of determining "data gaps" from the enqueued data.
And finally, maybe there is a more sexy way of using a waitEvent instead of isDone (for example, AutoResetEvent will allow 1 consumer through per producer .Set() call) but that is up to you to decide.
hope that helps!
--
- Jason
================================
Jason Swearingen Executive Director: Novaleaf Game Studios
--------------------------------------------------------------
Jas...@Novaleaf.com Cell:
+66-089-775-0111
Office:
+66-02-234-3031 Fax:
+66-02-234-3032================================