Выполнение, как предлагается в принятом ответе, приведет к множеству одновременных проблем, поскольку вы не можете гарантировать взаимное исключение с этим. Например, два потока, запрашивающие увеличение целого числа, оба одновременно будут считать логическое значение (которое предлагается в качестве блокировки), тогда оба будут думать, что все в порядке, и затем оба установят в bool противоположное значение. Оба потока будут вносить изменения, и когда они это сделают, они оба запишут значение в (не) взаимоисключающую переменную, и вся цель семафора будет потеряна. Метод wait () предназначен для ожидания, пока что-то не произойдет, и это именно то, что вы хотите сделать.
Если вы абсолютно не хотите использовать ожидание, тогда реализуйте какую-то технику сна с двойной проверкой, когда поток сначала проверяет переменную блокировки, изменяет ее на false и устанавливает флаг в массиве или что-то с помощью специального слота просто для этого потока, чтобы гарантировать, что он всегда будет успешным. Затем поток может спать в течение небольшого промежутка времени, а затем проверяет весь массив на наличие дополнительных флагов, чтобы увидеть, был ли кто-то еще в это же время. Если нет, он может продолжаться, иначе он не может продолжаться и вынужден спать в течение произвольного количества времени, прежде чем пытаться снова (чтобы потоки спали на отрезки времени, чтобы потом кто-то добился успеха). Если они снова рухнут, они будут спать еще дольше случайного времени. Этот метод также используется в сетях, где семафоры не могут быть использованы.
(Конечно, семафоры - это именно то, что вы хотите сделать, но поскольку они используют ожидание, я предположил, что вы хотели что-то, что вообще не использует ожидание ...)