Три типа потоков, пытающихся получить доступ к критическому разделу

Question

Для моего приложения я должен быть уверен, что в критический сеанс обрабатывается только один тип потока. Количество потоков для данного типа не указано и может быть «большим». Я пришел с простым решением:

MutableInt a,b,c; 
Semaphore mutex; 

void enterA() { 
    while (true) { 
     mutex.acquire(); 
     if (b.intValue() == 0 && c.intValue() == 0) { 
      a.increase(); 
      break; 
     } 
     mutex.release(); 
    } 
} 

void exitA() { 
    while(true) { 
     mutex.acquire(); 
     a.decrease(); 
     mutex.release(); 
    } 
} 

Я пропуск обработки исключений и B & C часть вызвать его просто копипаст.

Работает так, как ожидалось (возможность голодания голосом в порядке), но сгенерированная нагрузка слишком велика. Нитки постоянно проверяют счетчики. Я чувствую, что есть другое решение, но не могу придумать ни одного примера.

Answer 1

Я не могу определить, является ли ваше решение частью проблемы, но в ее нынешнем виде я бы рекомендовал переместиться на AtomicInteger, который обрабатывает все инкремент и т. Д. Для вас без блокировки.

Если это сложнее, вам следует рассмотреть возможность использования AtomicReference с некоторым классом аккумулятора и использовать метод compareAndSet(...) для его атомарного обновления.

Например, вы могли бы хранить 3 целых числа в MutableInts классе и сделать что-то вроде следующего:

final AtomicReference<MutableInts> reference = 
    new AtomicReference<MutableInts>(new MutableInts(0, 0, 0)); 
... 
do { 
    MutableInts ints = reference.get(); 
    // increment the ints properly which should generate a new MutableInts class 
    // it should _not_ make changes to `ints` itself 
    MutableInts newInts = ints.mutateSomehow(...); 
    // this spins in case some other thread updated it before us here 
} while (!reference.compareAndSet(ints, newInts)); 

Так что, похоже, как вы ограничены в вызовах можно использовать для достижения этой цели. Вот несколько других альтернатив:

• Каждый поток обновляет свои собственные данные, а затем каждый раз так часто (или, может быть, только в конце обработки) синхронизируется с центральными счетчиками. Такие же замки, но делают это лот реже.
• Каждый поток может обновлять потоки volatile счетчиков, а поток опроса может считывать счетчики и обновлять центральную информацию. Не уверен, разрешено ли volatile.