Отличия ADDR и OFFSET

Проясним момент насчет различия операторов ADDR и OFFSET в программах, написанных на Ассемблере.
Первоочередное назначение данных операторов - это получение адреса переменной в памяти.
В программах на ассемблере могут присутствовать как локальные так и глобальные переменные.
Глобальные переменные существуют в памяти на протяжении всего времени выполнения программы, локальные - только во время выполнения процедуры, в которой они определены, и удаляются как только она завершит работу. Поэтому адреса глобальных переменных известны уже на стадии ассемблирования, тогда как адреса локальных переменных в стеке станут известны только во время выполнения программы, а точнее при выполнении процедуры, в которой эти переменные объявлены.
Что касается операторов, то OFFSET вычисляет адрес уже размещенных к началу выполнения программы переменных, а это значит что данный оператор можно использовать для вычисления адресов только глобальных переменных.
С помощью оператора ADDR можно получить адрес локальной переменной.
Но почему так получается, что с помощью ADDR можно узнать адрес локальной пременной, а с помощью OFFSET - нельзя. Дело в том, что ассемблер, встретив оператор ADDR, использующийся с локальной переменной, генерирует последовательность инструкций

lea eax, localVar
push eax

ну а инструкция lea уже делает свое дело. Т.к. ADDR превращается в выше указанную посдедовательность инструкций, данный оператор можно использовать только с директивой invoke для передачи адреса переменной в качестве параметра. Присваивание регистру полученного таким способом адреса невозможно. ADDR можно так же использоваться и с глобальными переменными. В этом случае ассемблер сгенерирует

push offset globalVar

И в отличие от OFFSET, ADDR не умеет вычислять смещения меток, определенных далее в коде.

mov eax, offset l1 ; так можно
invoke Foo, ADDR l1; так нельзя
l1:
xor ebx, ebx
invoke Foo, ADDR l1; так можно

EFLAGS. Перенос (CF) и переполнение (OF)

Есть в процессоре (будем говорить об архитектуре Intel) такой замечательный регистр - EFLAGS или регистр флагов. Данный 32-битный регистр содержит группу статусных флагов, группу флагов контроля и группу системных флагов. Как правило, в учебниках по архитектуре компьютера или ассемблеру присутствует довольно сухое описание, для чего определенный флаг предназначен, и еще чаще отсутствуют примеры, связанные с данным флагом. Рассмотрим два важных флага - флаг переноса (carry flag - CF) и флаг переполнения (overflow flag - OF) и постараемся более подробно осветить эту тему, чем в обычно это делают в учебниках.
Из руководства "Intel Software developer`s manual vol.1" (перевод):
CF - устанавливается, если в результате арифметической операции произошло переполнение разрядной сетки либо заем из старшего бита. Флаг свидетельствует о переполнении для беззнаковых чисел.

Будем рассматривать все на примере 8-битных чисел/регистров.
С переполнением разрядной сетки все достаточно просто. Диапазон беззнаковых чисел, которые могут быть представлены 8 битами - это 0...255. Следовательно переполнение наступит, если результатом выполнения операции будет число больше 255.

    clc
    mov al, 250
    mov bl, 10
    add al, bl ; должно быть 260, но на деле в al 4

В данном случае число не помещается в 8 бит, и возникает переполнение.

Рассмотрим числа 8 и 6. Что будет если из 6 вычесть 8? В двоичном представлении 6 имеет вид 00000110, 8 - 00001000. При поразрядном вычитании в 4 бите произойдет заем, который породит заем из 5,6,7,8 битов. Т.е. в итоге происходит заем из старшего бита, а это значит что флаг переноса устанавливается.

    clc
    mov al, 6
    mov bl, 8
    sub al, bl ; теперь в al -2

Для чего в данном случае устанавливается флаг. Дело в том, что результат получается отрицательным, что логично, но это неверно для беззнаковых чисел, которые по определению не могут иметь отрицательного значения. Т.е. результат опять не входит в диапазон 0...255 Из этого можно сделать вывод - если происходит вычитание большего числа из меньшего, то флаг переноса будет установлен, т.к. в этом случае происходит заем из старшего бита.
А при сложении отрицательного и положительного (минус на минус дает плюс) и получая по сути тот же результат, флаг переноса устанавливаться не будет, несмотря на то, что результат является слишком малым и не входит в диапазон 0...255. Дело в том, что отсутствует заем из старшего бита.

    mov al, -79
    mov bl, 49
    add al, bl ; CF = 0

Но если взять вместо -79 число -49, то флаг переноса установится, т.к. -49 для беззнаковых чисел равно 207, а 207+49=256, что является переполнением 8 бит.
Флаг переноса полезен при работе с большими числами, не помещающимися в 32-разрядный регистр. Например, если требуется сложить 2 числа, каждое из которых расположено в паре 32-рязрядных регистров.

Рассмотрим флаг переполнения.
Из руководства "Intel Software developer`s manual vol.1" (перевод):
Флаг OF устанавливается, если число - слишком большое положительное, либо слишком маленькое отрицательное. Флаг свидетельствует о переполнении для знаковых чисел.
Диапазон знаковых чисел в 8-битном случае -128...127, т.е., как сказано в руководстве, 2 варианта:

• Число слишком мало для представления в виде 8-битного знакового
• Число слишком велико для представления в виде 8-битного знакового

Первый случай:

    mov al, 117
    mov bl, 92
    add al, bl ;

В итоге имеем -47 вместо 209 из-за переноса в знаковый бит, т.е. число 209 выходит за допустимый диапазон сверху.
Второй случай:

    mov al, -20
    mov bl, -118
    add al, bl ;

Складываем 2 отрицательных числа и получаем тем не менее положительную сумму (118 вместо -138), т.к. -138 выходит за допустимый диапазон снизу.
Но что такое "знаковые числа"? Как процессор понимает, когда используется знаковое, а когда - беззнаковое число. На самом деле процессор не знает этого. Он сразу предполагает оба случая и в соответствии с этим выставляет флаги.

Многопоточное программирование. 3. Проблема производителя и потребителя

Проблема производителя и потребителя, известная так же как проблема ограниченного буфера, является одной из классических задач многопроцессной синхронизации.

Рассмотрим упрощенный случай с двумя процессами. Первый процесс - Производитель (Producer), второй - Потребитель (Consumer).
Процессы используют общий буфер: Производитель помещает информацию в буфер, в то время как Потребитель извлекает ее, независимо от Производителя. Для Производителя всегда должно присутствовать незанятое место (слот) для записи информации, тогда как для Потребителя информация для извлечения должна присутствовать всегда, т.е. как минимум один непустой слот.
Производитель надеется на Потребителя, что тот предоставит свободное место для вставки очередной порции информации, а Потребитель надеется на Производителя, что тот обеспечит информацию для извлечения.
В таком случае Производитель и Потребитель каким-то образом должны взаимодействовать между собой, чтобы знать, что очередная вставка/извлечение будет безопасной для работающего в данный момент одного из процессов.

На первый взгляд решение, представленное ниже, абсолютно верное:

#define MAX_SIZE 100
int count = 0;
Producer()
{
  while (TRUE)
  {
    item = ProduceItem();
    if (count == MAX_SIZE) // (1) если буфер полон
    sleep(); // (2)
    InsertItem(item);
    ++count;
    if (count == 1)// был ли буфер пуст
      wakeup(Consumer);
  }
}

Consumer()
{
  while(TRUE)
  {
    if (count == 0) // (3) если буфер пуст
      sleep(); // (4)
    item = RemoveItem();
    --count;
    if (count == MAX SIZE - 1) // был ли буфер полон
      wakeup(Producer);
    ConsumeItem(item);
  }
}

count - количество слотов информации (или товаров, кому как) в буфере.
MAX_SIZE - максимальный размер буфера
Производитель сначала проверяет, не полон ли буфер, и если буфер полон, то Производитель засыпает, если не полон, то помещает информацию, увеличивает счетчик занятых слотов, и проверяет, не был ли буфер пусто до этого, если был пуст - значит Потребитель спит, и его надо разбудить.
Потребитель же наоборот, засыпает, когда буфер оказывается пустым. Если же после извлечения очередного элемента, Потребитель узнает, что до этого буфер был полным, значит Производитель спит и его надо разбудить.
Но в жизни все не так :-)

Представим, что буфер полон и работает Производитель. Осуществляется проверка на полноту буфера, и внезапно после выполнения строки (1), т.е. когда стало уже известно что надо заснуть, произошло переключение процесса. Теперь работает Потребитель. Он исправно извлекает информацию. Очистив первый слот, Потребитель понимает что буфер был полон, и нужно разбудет спящего, как ему кажется, производителя. Потребитель посылает сигнал пробуждения, и очищает буфер до конца, после чего засыпает. После этого происходит переключение на процесс Производителя, который не спал, а только собирался, и теперь он готов осуществить свою мечту - немного поспать. И засыпает. Все спят. Взаимоблокировка или deadlock.
А проблема, как уже многие догадались, состоит в утраченном вызове активизации процесса. Т.е. Производитель не спал, а его будили. К аналогичному результату привело бы рассмотрение ситуации, если бы буфер оказался пустым, и Потребитель решил бы уснуть, но "не успел".

Итак. Попробуем устранить проблему утраченного сигнала. Для этого будем использовать семафоры.
Cемафор - переменная, как правило целочисленная, используется для синхронизации доступа множества параллельно работающих процессов/потоков к общему ресурсу. Между семафором и обыкновенной численной переменной есть различия:

• Будучи созданным, семафору можно присвоить любое значение (для counting semaphore), но операции, которые могут работать с семафором, ограничиваются лишь инкрементом и декрементом
• Когда процесс/поток уменьшает значение семафора, и результат становится отрицательным, то он блокирует сам себя, и не может продолжать выполнение, пока другой процесс/поток не увеличит значение семафора
• Если процесс/поток инкрементирует значение семафора, и есть ожидающие процессы, то один из них разблокируется

В нашем решении мы будем использовать 2 вида семафоров:

• Counting semaphore (подсчитывающий)
• Binary semaphore (двоичный, или мьютекс)

Вообще говоря, мьютекc и двоичный семафор это не одно и то же. Правильнее будет рассуждать, что двоичный семафор может быть использован как мьютекс, но не наоборот.
Двоичный семафор будет использоваться для управления доступом к буферу (чтобы в данный момент только один из потоков, а их может быть очень много, имел доступ к критической секции)
Подсчитывающие семафоры буду использоваться для подсчета свободных и занятых слотов буфера

#define MAX_SLOTS 100
typedef int semaphore;
semaphore mutex = 1;
semaphore empty = N; // подсчет пустых слотов в буфере
semaphore full = 0; // подсчет заполненных слотов буфере
Producer()
{
  int item;
  while (TRUE)
  {
    item = ProduceItem();
    down(empty); // (1)
    down(mutex); // (2)
    EnterItem(item);
    up(mutex); // (3)
    up(full); // (4)
  }
}
Consumer()
{
  int item;
  while (TRUE)
  {
    down(full); // (5)
    down(mutex); // (6)
    item = RemoveItem();
    up(mutex); // (7)
    up(empty); // (8)
    ConsumeItem(item);
  }
}

Итак, mutex отвечает за доступ одного процесса/потока в данный момент времени. Разберемся с empty и full. Пусть какое-то время программа работает, затем буфер заполняется полностью. Пусть в это время работает Производитель. Если буфер заполнен полностью, то empty = 0, это значит, что команда down(empty) приведет к блокировке Производителя (вспоминаем пункт 2 о семафорах). Далее работает Потребитель, разгружает слоты, регулирует семафоры количества пустых и полных слотов (количество пустых растет), и после первого очищения слота, Производитель может быть разблокирован, т.к. значение семафора увеличилось. Допустим произошло переключени на Производителя. Он продолжает выполнение со строки (2), заходит в критическую секцию, заполняет слот, выходит и увеличивает количество заполненных ячеек, тем самым позволяя Потребителю (если тот заблокирован) разблокироваться. В том и разница, что в данном случае Производитель не производит насильную разблокировку Потребителю, не задумываясь, надо ли это ему, а лишь создает условия, необходимые для разблокировки в случае, если таковая потребуется. Читателю предлагается проверить оставшиеся три граничные ситуации:

• Буфер полон, работает Потребитель
• Буфер пуст, работает Производитель
• Буфер пуст, работает Потребитель

Уфффф!