Is it better to have Custom Thread Pool in .NET using one AutoResetEvent per Thread or one Semaphore across all the threads?

Question

First of all my apologies for a verbose request.

I have an infrastructure with a number threads that each wait on their on WaitHandle (AutoResetEvent) till an activity is queued to it. I am thinking of changing that infrastructure for the following reason. Each thread works on its own activity. ( I have a set of different activities to be managed).

The disadvantage I presume of the current infrastructure is that I have as many wait handles as the number of the threads(activities) themselves and which(thread count) can keep increase or decrease.

The current logic is as follows A set of threads each associated with its own AutoResetEvent & activity Thread1-Event1-activity1 Thread2-Event2-activity2

Activity
{
   Thread th;
   AutoResetEvent ev;
   Operation();
}

Each thread executes a loop and performs an operation within the loop.

pseudo code as follows.

while(event.Wait())
{
   //Execute operation (activity-n)
}

So the controller that queues operations to the thread simply sets the event and the thread completes its task and goes back to wait for the next request of activity-n

Activity.event.Set();

The infrastructure that I have in mind to reduce the number of WaitHandles being used is to go with one Semaphore across all the threads.

Set Semaphore count to an arbitrary max number of 100. Set initial count of semaphore to 0.

Semaphore sem = new Semaphore(0,100); 
Thread [] threads = new Threads(100);

Now the semaphore is essentially in a locked state for all the threads.

All threads now execute the loop as before

while(sem.Wait())
{
       //deque activity
       //perform activity

}

Except that there is no fixed thread for an activity (the activity gets queued to a centralized concurrent queue). The controller that queues the activity performs the following operation.

queue.Enqueue(activity-n);

//To release one of the threads from the waiting threads to execute the activity.
semaphore.Release(1). 

Would the semaphore implementation be better than the multiple WaitHandle approach? If so why? I do feel that a single Semaphore approach means increased contention.

If anyone could throw some light on this. it would be great.

Update: I haven't used the BlockingCollection because my queuing of requests is a little unique. I have the condition that I have multiple kinds of activities (type 1 through n) and more than activity of the same type (say n) cannot be acted upon when one activity of type n is being acted upon. Which is why initially I had one thread per activity type. I was trying to reduce the wait handles involved to 1 which is why I am trying to see if the semaphore approach will fit. However my concern is that if I go to the Semaphore route, I will be increasing the lock contention. In my scenario I will probably have one or two threads active at any time, meaning all the remaining threads will be contending for the one or two open slots in the semaphore that have been opened up.