Microsoft visual basic queues

Introduction

This module describes the basics of Visual Basic queues and also describes the AutoResetEvent event.

Reading

• Queue Class: (External Link)
• Queue members: (External Link)
• Queue.Synchronized Method: (External Link)
• AutoResetEvent Class: (External Link)

Queues

Queues in Visual Basic (VB) are very simple to work with and very flexible. Defining a queue object is done with the following command:

This creates a single queue object named myQ . The main methods described in this module are:

The Enqueue method puts items on the queue and the Dequeue method takes items off the queue. With these two methods the queue works as a first-in-first-out (FIFO) type of queue. A property of the queue object that is very useful is the count property:

This returns the number of items in the queue.

VB queues are not thread safe. This means that the operating system does not prevent multiple threads from modifying a queue at the same time. This can cause problems if you have multiple threads reading and writing to the same queue.

If you have multiple threads removing items from a queue you can run into problems. If a thread accesses the count property and it says there is an object on the queue and then the thread tries to access that element, another thread may remove it from the queue before the first thread has a chance to access it. If there is only one thread that removes items from a queue you will not have this problem.

To assure that a queue is thread safe you should use the Synchronized method of the queue. This method returns a wrapper for the queue that assures that the queue is thread safe. It does not fix the problem where two threads are taking items off the queue at the same time though. To use the Synchronized method first make a queue object and then make an object with the Synchronized method.

The queue mySyncdQ is a thread safe queue.

To synchronize threads that communicate using a queue, there is a need for the writing thread to inform the reading thread that there is something available on the queue. This signaling prevents the reading thread from wasting time checking to see if anything is available on the queue. The reading thread will simply wait to be signaled that something is on the queue and then it will access the queue. To do this you can use an AutoResetEvent event.

From the MSDN help files: " AutoResetEvent allows threads to communicate with each other by signaling. Typically, this communication concerns a resource to which threads need exclusive access. A thread waits for a signal by calling WaitOne on the AutoResetEvent . If the AutoResetEvent is in the non-signaled state, the thread blocks, waiting for the thread that currently controls the resource to signal that the resource is available by calling Set . Calling Set signals AutoResetEvent to release a waiting thread. AutoResetEvent remains signaled until a single waiting thread is released, and then automatically returns to the non-signaled state. If no threads are waiting, the state remains signaled indefinitely. If a thread calls WaitOne while the AutoResetEvent is in the signaled state, the thread does not block. The AutoResetEvent releases the thread immediately and returns to the non-signaled state. There is no guarantee that every call to the Set method will release a thread. If two calls are too close together, so that the second call occurs before a thread has been released, only one thread is released. It is as if the second call did not happen. Also, if Set is called when there are no threads waiting and the AutoResetEvent is already signaled, the call has no effect."