Насколько я помню, в WIN32 присвоения указателей типа PVOID и переменных типа (LONG, ULONG, INTPTR, UINTPTR) атомарны, соответственно атомарны и присвоения указателей эквивалентного размера. Так, что скорее всего проблемы не в присвоении, а в алгоритме. По поведению - типичный race conditions. Обычный способ отладки - изучение алгоритма или, если ничего не приходит в голову, расстановка вызовов Sleep(0) (особенно полезно их вызвать перед и после функций ожидания).

Tubrik MasterZiv
Медленнее не станет покидать. Но если у тебя в системе есть
более высокоприоритетные потоки (что наверняка), то есть риск,
что обновляющий поток никогда не получит управление (или очень
нескоро получит) и не освободит данные.


Ага, именно это меня и интересовало, т.е. если в системе есть более приоритетные процессы (а они конечно же есть, хотябы потому, что обновляющий поток с приоритетом ниже нормального), то обновляющий поток будет дольше обрабатывать разделяемый реруср, а значит запросы буду дольше ждать. Выходит то, ради чего его приоритет занижался (ради уступания времени запросам), выполняться не будет? Обновляющий поток никогда не получит управления, только если потоки с более высоким приоритетом всегда планируются на исполнение. При правильно написанных программах такое может произойти только если не хватает вычислительной мощности процессора. Как правило, в этом случае заменяется компьютер, потому, что работать на нем все равно невозможно. В случаях, когда высокоприоритетный поток ожидает освобождения ресурса занятого низкоприоритетным рабочим потоком система должна поднимать приоритет рабочего потока. В Win32 это точно делается (msdn):

Priority Inversion
Priority inversion occurs when two or more threads with different priorities are in contention to be scheduled. Consider a simple case with three threads: thread 1, thread 2, and thread 3. Thread 1 is high priority and becomes ready to be scheduled. Thread 2, a low-priority thread, is executing code in a critical section. Thread 1, the high-priority thread, begins waiting for a shared resource from thread 2. Thread 3 has medium priority. Thread 3 receives all the processor time, because the high-priority thread (thread 1) is waiting for shared resources from the low-priority thread (thread 2). Thread 2 won't leave the critical section, because does not have the highest priority and won't be scheduled.

The scheduler solves this problem by randomly boosting the priority of the ready threads (in this case, the low priority lock-holders). The low priority threads run long enough to exit the critical section, and the high-priority thread can enter the critical section. If the low-priority thread doesn't get enough CPU time to exit the critical section the first time, it will get another chance during the next round of scheduling.

Windows Me/98/95: If a high-priority thread is dependent on a low-priority thread that will not be allowed to run because a medium priority thread is getting all of the CPU time, the system recognizes that the high-priority thread is dependent on the low-priority thread. It will boost the low-priority thread's priority up to the priority of the high-priority thread. This will allow the thread that formerly had the lowest priority to run and release the high-priority thread that was waiting for it.

MasterZiv
teras пишет:

> Насколько я помню, в WIN32 присвоения указателей типа PVOID и переменных
> типа (LONG, ULONG, INTPTR, UINTPTR) атомарны, соответственно атомарны и
> присвоения указателей эквивалентного размера.

Откуда такие сведения ?
Posted via ActualForum NNTP Server 1.4 Традиционно - MSDN.

Interlocked Variable Access
The interlocked functions provide a simple mechanism for synchronizing access to a variable that is shared by multiple threads. The threads of different processes can use this mechanism if the variable is in shared memory.

Simple reads and writes to properly-aligned 32-bit variables are atomic. In other words, when one thread is updating a 32-bit variable, you will not end up with only one portion of the variable updated; all 32 bits are updated in an atomic fashion. However, access is not guaranteed to be synchronized. If two threads are reading and writing from the same variable, you cannot determine if one thread will perform its read operation before the other performs its write operation.

Simple reads and writes to properly aligned 64-bit variables are atomic on 64-bit Windows. Reads and writes to 64-bit values are not guaranteed to be atomic on 32-bit Windows. Reads and writes to variables of other sizes are not guaranteed to be atomic on any platform.

То есть, операции чтения и записи 32-битных, выровненных значений - атомарны. Выравнивание по умолчанию у VC - или 4 или 8 байт.

Tubrik teras


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

White Owl terasНасколько я помню, в WIN32 присвоения указателей типа PVOID и переменных типа (LONG, ULONG, INTPTR, UINTPTR) атомарны, соответственно атомарны и присвоения указателей эквивалентного размера.Это не совем верно, Win32 здесь не при чем. На самом деле, атомарны операции записи регистра процессора в память. Конечно, вы правы, атомарность реализуется на аппаратном уровне. Но это несколько другое. Наличие таких ограничений в спецификации обозначает то, что Win32 никогда не будет портирован под платформы, где присвоение LONG будет не атомарным, а значит этим можно пользоваться, вне зависимости от типа процессора.

TubrikЧто такое блокировки на чтение/запись? Повышение гранулянтности блокировок по уровню доступа. Читатели и писатели взаимоисключающи. При этом в критическую секцию, одновременно может войти несколько читателей. Писатель может быть либо один, либо несколько, в зависимости от реализации. Хороший пример реализации можно найти в pthreads/win32.