This is a very bad idea.

A counting semaphore is fundamentally the wrong mechanism(*) for watermarking a queue; so futzing with the API of a counting semaphore to allow it to be used (badly) for this purpose is just all kinds of wrong.

(*)In brief, A counting semaphore is designed for controlling concurrent access to a resource that is limited but has multiple instantiations.

A queue, even a pre-limited queue, does not fit this criteria.

1. a queue can only be accessed by one user (reader or writer) at a time, regardless of how much is does or can contain.
2. the availability of a queues resources is not determined by the actions of competing consumers -- the reason d'etre of the counting semaphore -- but rather by the actions of the producer.

   They are very different animals.

3. Having the consumer(s) of a queue effectively control the producer(s) for that queue, requires multi-way synchronisation, and defeats the primary purpose of the queue: that of acting as a flexible buffer between producers and consumers to avoid the need for and problems associated with such synchronisation.

   Those problems include:

   Consumers and producers can become 'step-locked'.

   The flow falls into a pattern of the consumer(s) all wasting many time-slices (and expensive context switches) waiting for the producer(s). Then alternately, the producer(s) all waste time-slices waiting for the consumer(s). The flow becomes lock-stepped wasting many context switches between each forward step.

   The very purpose of queues is to alleviate this problem by acting as a flexible buffer removing the need for synchronisation.

See 940030 for a little more discussion.