Первый:
acquire_semaphore(struct semaphore s)
Когда это вызывается, семафор предоставляется значением и почти наверняка должно быть ссылкой . Когда оно равно значению , любые изменения, сделанные при приобретении, вообще не отражаются в s [см. Примечание 1]. Итак, что бы ни делало приобретение, оно не обеспечивает семантику получения семафора. То же самое, скорее всего, относится к ссылкам на неопределенные типы очередей (s-> m, s-> h).
Это еще один класс c:
}
else
s.mutex = FALSE;
SIGNAL(s.m);
Что на самом деле понимается компилятором как:
} else {
s.mutex = FALSE;
}
SIGNAL(s.m);
Что не кажется правильным, но многое кажется неправильным. Так что, если это вообще что-то делает, это случайно (может быть, неудача?). Игнорируйте его, если только вам не назначено его исправить.
Во-вторых, он пытается реализовать семафоры поверх WAIT & SIGNAL, которые эквивалентны семафору; Вполне вероятно, что его можно исправить следующим образом:
struct semaphore {
queue s;
};
acquire_semaphore(struct semaphore *s) {
WAIT(&s->s);
}
release_semaphore(struct semaphore *s) {
SIGNAL(&s->s);
}
и покончить с ним.
[примечание]: разумно расположить семафор следующим образом:
struct semaphore {
struct _semaphore *p;
};
struct _semaphore {
/* actual bits to make a semaphore here */
};
Который имеет приятный эффект разрешения семантики копирования в семафоре, поэтому, если кто-то делает что-то вроде перераспределения структуры, содержащей семафор, он ведет себя, как и ожидалось. Это не делается в этом примере, но это хорошо запомнить.