CLCommandQueueMBS.Constructor(context as CLContextMBS, device as CLDeviceMBS, flags as Integer = 0)

Var devices(-1) as CLDeviceMBS = OpenCLMBS.AllDevices(CLDeviceMBS.kDeviceTypeGPU)
Var device as CLDeviceMBS = devices(0) // we use first one

// Create a context
Var context as new CLContextMBS(device, CLContextMBS.kErrorModeLogMessagesToSystemLog)

// Create a command queue
Var queue as new CLCommandQueueMBS(context, device, 0)

context: Must be a valid OpenCL context.
device: Must be a device associated with context. It can either be in the list of devices specified when context is created using CLContextMBS Constructor or have the same device type as the device type specified when the context is created.
flags: Specifies a list of properties for the command-queue. This is a bit-field. Only command-queue properties specified in the table below can be set in properties; otherwise the value specified in properties is considered to be not valid.

Command-Queue Properties	Description
kQueueOutOfOrderExecModeEnable	Determines whether the commands queued in the command-queue are executed in-order or out-of-order. If set, the commands in the command-queue are executed out-of-order. Otherwise, commands are executed in-order.
kQueueProfilingEnable	Enable or disable profiling of commands in the command-queue. If set, the profiling of commands is enabled. Otherwise profiling of commands is disabled. See clGetEventProfilingInfo for more information.

The OpenCL functions that are submitted to a command-queue are enqueued in the order the calls are made but can be configured to execute in-order or out-of-order. The properties argument in clCreateCommandQueue can be used to specify the execution order.

If the kQueueOutOfOrderExecModeEnable property of a command-queue is not set, the commands enqueued to a command-queue execute in order. For example, if an application calls EnqueueNDRangeKernel to execute kernel A followed by a EnqueueNDRangeKernel to execute kernel B, the application can assume that kernel A finishes first and then kernel B is executed. If the memory objects output by kernel A are inputs to kernel B then kernel B will see the correct data in memory objects produced by execution of kernel A. If the kQueueOutOfOrderExecModeEnable property of a commandqueue is set, then there is no guarantee that kernel A will finish before kernel B starts execution.

Applications can configure the commands enqueued to a command-queue to execute out-of-order by setting the kQueueOutOfOrderExecModeEnable property of the command-queue. This can be specified when the command-queue is created or can be changed dynamically using this Constructor. In out-of-order execution mode there is no guarantee that the enqueued commands will finish execution in the order they were queued. As there is no guarantee that kernels will be executed in order, i.e. based on when the EnqueueNDRangeKernel calls are made within a command-queue, it is therefore possible that an earlier EnqueueNDRangeKernel call to execute kernel A identified by event A may execute and/or finish later than a EnqueueNDRangeKernel call to execute kernel B which was called by the application at a later point in time. To guarantee a specific order of execution of kernels, a wait on a particular event (in this case event A) can be used. The wait for event A can be specified in the event_wait_list argument to EnqueueNDRangeKernel for kernel B.

In addition, a wait for events or a barrier command can be enqueued to the command-queue. The wait for events command ensures that previously enqueued commands identified by the list of events to wait for have finished before the next batch of commands is executed. The barrier command ensures that all previously enqueued commands in a command-queue have finished execution before the next batch of commands is executed.

Similarly, commands to read, write, copy or map memory objects that are enqueued after EnqueueNDRangeKernel, EnqueueTask or EnqueueNativeKernel commands are not guaranteed to wait for kernels scheduled for execution to have completed (if the kQueueOutOfOrderExecModeEnable property is set). To ensure correct ordering of commands, the event object returned by EnqueueNDRangeKernel, EnqueueTask or EnqueueNativeKernel can be used to enqueue a wait for event or a barrier command can be enqueued that must complete before reads or writes to the memory object(s) occur.

Lasterror is set.

CLCommandQueueMBS.Context as CLContextMBS

Lasterror is set.

CLCommandQueueMBS.Device as CLDeviceMBS

Lasterror is set.

CLCommandQueueMBS.Finish

Blocks until all previously queued OpenCL commands in command_queue are issued to the associated device and have completed.

Finish does not return until all queued commands in command_queue have been processed and completed. clFinish is also a synchronization point.

Lasterror is set.

CLCommandQueueMBS.Flush

Issues all previously queued OpenCL commands in command_queue to the device associated with command_queue.

Flush only guarantees that all queued commands to command_queue get issued to the appropriate device. There is no guarantee that they will be complete after Flush returns.

Lasterror is set.

Any blocking commands queued in a command-queue such as EnqueueReadImage or EnqueueReadBuffer with BlockingRead set to true, EnqueueWriteImage or EnqueueWriteBuffer with BlockingWrite set to true, EnqueueMapImage or EnqueueMapBuffer with BlockingMap set to true or WaitForEvents perform an implicit flush of the command-queue.

To use event objects that refer to commands enqueued in a command-queue as event objects to wait on by commands enqueued in a different command-queue, the application must call a Flush or any blocking commands that perform an implicit flush of the command-queue where the commands that refer to these event objects are enqueued.
Lasterror is set.

CLCommandQueueMBS.Properties as UInt32

Lasterror is set.

CLCommandQueueMBS.ReferenceCount as UInt32

Lasterror is set.