Generic Task Blocking Queue

A generic blocking queue has the following properties:

• It is thread-safe.

• It allows queuing and de-queuing of items of a certain type (T).

• If a de-queue operation is performed and the queue is empty, the de-queuing thread waits indefinitely for an item to be queued and then

retrieves it (i.e. a de-queue operation cannot fail or return no
item).


Assuming we want to implement a client application that simulates the operation of such a queue.

The application allows the user to do the following:

-
Start a number of de-queuing worker threads by doing the following:

a. Specify the number of worker threads (w).

b. Press the "Start" button.

By pressing the "Start" button, w worker threads are created and start de-queuing and executing the tasks in the queue. Completed tasks display their results in the results list.
Each result shows the executing worker thread id and the result itself.

-
Queue tasks by doing the following:

a. Choose a task type.

b. Initialize its parameters.

c. Specify the number of queuing threads (n) and the number queued tasks (t) for each thread.

d. Press the "Queue" button.

The user can queue 3 types of tasks (of course, many more tasks could be created) :

-
A task that receives 2 integers as inputs, adds them and returns the result.

-
A task that receives 2 strings as inputs, concatenates them and returns the result.

-
A task that receives a string as an input and returns whether the string is a palindrome.

Upon pressing the button, n threads are created, each creates t instances of the task and queues them all.


Some useful guidelines:

• Design the UI in WinForms or WPF, or whatever technology you're comfortable with.

• Separate the different application layers (BL, UI, etc.)

• Write code that allows easy addition of other task types to the system with minimal change to existing code.

The question is a request for code-review on the design of the classes, interfaces
and logic o

This is a 10-in-1 question. This answer is taking a quick look at SimulatorForm.cs.

What you mention at the end of your [epic] post, that you've chosen reflection but that you could have used an enumeration of IoC containers instead, leaves me perplexed.

Inversion of Control implies letting go of control. Your MainForm has an empty constructor that loads assemblies, fetches static configurations and populates a combobox. I think that's a lot to do for a constructor. I don't think usage of reflection is warranted here, at all. In fact I find it just obfuscates the intent. Go ahead, inject your dependencies! Your usage of reflection isn't too far off from some all-powerful Service Locator that can instantiate just about anything.

Also maybe it's because I'm getting quite fond of commands, but I find you have a lot going on in those event handlers, beyond what would be the job of a presentation layer - i.e. deal with presentation concerns, delegating the actual work elsewhere. As a result, your code-behind feels bloated with mixed concerns:

• tasksComboBox_SelectedIndexChanged is purely presentation stuff. That's good.

• EnqueueTasksThreadFunc clearly belongs somewhere else, and it being public and static is kind of scary.

• EnqueueConcurrent probably belongs in the same type as EnqueueTasksThreadFunc.

• queueButton_Click and startDequeueButton_Click actually implement your "business logic".

I realize event handlers are named after the objects that they handle events for, but still I would rename them so as to keep a consistent PascalCasing for all methods. The objectName_EventName convention feels like VB6 - you're free to name you handlers as you like them, e.g. "OnQueueButtonClick"

StackExchange Code Review Q#26497, answer score: 2