mira, у TryEnterCriticalSection можно задать таймаут, после которого если так и не удалось войти в секцию, то TryEnterCriticalSection завершается возвращая соответствующий код результата. Собсно даже не можно а нужно, и так же от 0 до INFINITE
__________________
Я здесь практически не появляюсь!, Skype - ikskor
mira, у TryEnterCriticalSection можно задать таймаут...
Где?
Цитата:
Сообщение от mira
впервые слышу что у секции есть таймаут.
Я нашел только глобальный:
Цитата:
The timeout interval is specified by the following registry value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session Manager\CriticalSectionTimeout.
ненадо там ниче проверять. опиратса на эти поля крайне не рекомендуетса (как и на саму структуру). кроме как большего гемора не получиш.
LockCount - это типа счетчик запираний (у секции поидеи 0 или 1)
OwningThread - ид потока вошедшего в секцию
LockSemaphore - помоему для случая какраз с трайэнтером (иначе не используетса)
LockCount - это типа счетчик запираний (у секции поидеи 0 или 1)
а мне кажется это для счётчика потоков ожидающих входа в секцию
Добавлено через 7 минут
а хотя...
Цитата:
Сообщение от msdn
The most important fields of the critical section structure are as follows:
In Microsoft Windows 2000, and Windows XP, the LockCount field indicates the number of times that any thread has called the EnterCriticalSection routine for this critical section, minus one. This field starts at -1 for an unlocked critical section. Each call of EnterCriticalSection increments this value; each call of LeaveCriticalSection decrements it. For example, if LockCount is 5, this critical section is locked, one thread has acquired it, and five additional threads are waiting for this lock.
The RecursionCount field indicates the number of times that the owning thread has called EnterCriticalSection for this critical section.
The EntryCount field indicates the number of times that a thread other than the owning thread has called EnterCriticalSection for this critical section.
When the first thread calls the EnterCriticalSection routine, the critical section's LockCount, RecursionCount, EntryCount and ContentionCount fields are all incremented by one, and OwningThread becomes the thread ID of the caller. EntryCount and ContentionCount are never decremented.
At this point, four different things can happen.
The owning thread calls EnterCriticalSection again. This will increment LockCount and RecursionCount. EntryCount is not incremented.
A different thread calls EnterCriticalSection. This will increment LockCount and EntryCount. RecursionCount is not incremented.
The owning thread calls LeaveCriticalSection. This will decrement LockCount (to -1) and RecursionCount (to 0), and will reset OwningThread to 0.
Another thread calls LeaveCriticalSection. This produces the same results as the owning thread calling LeaveCriticalSection -- it will decrement LockCount (to -1) and RecursionCount (to 0), and will reset OwningThread to 0.
When any thread calls LeaveCriticalSection, Windows decrements LockCount and RecursionCount. This feature has both good and bad aspects. It allows a device driver to enter a critical section on one thread and leave the critical section on another thread. However, it also makes it possible to accidentally call LeaveCriticalSection on the wrong thread, or to call LeaveCriticalSection too many times and cause LockCount to reach values lower than -1. This corrupts the critical section and causes all threads to wait indefinitely on the critical section.
__________________
Я здесь практически не появляюсь!, Skype - ikskor
Последний раз редактировалось xkor, 25.08.2011 в 01:19.
Причина: Добавлено сообщение