Added test to verify flush on clReleaseCommandQueue with multiple queues

[shajder]

Fixes #2087 according to task description.

[bashbaug]

@kpet can you check that the test description in #2087 is correct?

This test follows the test description exactly (thanks!), but I would like to ensure it is properly testing that the flush happsn on clReleaseCommandQueue and not somewhere else (e.g. the clFinish).

[bashbaug]

Since we've called clFinish on queue_B here, the event_B must already be CL_COMPLETE.

[kpet]

@bashbaug I've reviewed the description and I think I still mostly agree with this. This won't prevent implementations from flushing queue A when clFinish is called on queue B (or elsewhere, they have the freedom) but, importantly, it should never deadlock because of work in queue B that depends on the unflushed work in queue A (because of the prior call to clReleaseCommandQueue on queue A.

Deadlocking is not a great failure mode for a test though so maybe we could call clFlush instead of clFinish on queue B and pool the event's execution status for the command that went to queue B instead.

The following single queue test could be useful to have too:

• Enqueue work in a queue and get an event
• Call clReleaseCommandQueue on that queue
• Poll the execution status of the event, it should transition to CL_COMPLETE "soon".

[lakshmih]

Agree that clFlush on queue B rather than clFinish is more appropriate to prevent the test from deadlocking when the flush on clReleaseCommandQueue is missing.

[bashbaug]

OK, to be clear, I don't think this test is wrong with either the explicit call to clFinish() (or an explicit call to clFlush() instead), but I also think it could very likely be testing behavior other than the implicit flush on clReleaseCommandQueue.

I think that the proposed single-queue test would be more useful:

• Enqueue work in a queue and get an event
• Call clReleaseCommandQueue on that queue
• Poll the execution status of the event, it should transition to CL_COMPLETE "soon".

If we really wanted to test the letter of the spec, we should also call clRetainCommandQueue on the queue first, so the call to clReleaseCommandQueue decrements the reference count but doesn't cause the reference count to reach zero. This is the behavior we are considering changing - linking in KhronosGroup/OpenCL-Docs#1248 (comment).