pPrevObject;
m_lockObject.Lock ();
pPrevObject.Attach (m_pObject.Detach ());
m_pObject = pNewobject;
m_lockObject.Unlock ();
// pPrevObject.Release ();
)
Тепер потенційно останній дзвінок
IObject2:: Release () буде здійснений після виходу з критичної секції. А
присвоєння нового значення як і раніше синхронізовано з викликом
IObject2:: SomeMethod () з нитки № 1.
Способи виявлення помилок
Спочатку варто звернути увагу на
"офіційний" спосіб виявлення блокувань. Якби окрім
:: EnterCriticalSection () і:: TryEnterCtiticalSection () існував ще й
:: EnterCriticalSectionWithTimeout (), то достатньо було б просто вказати
якесь резонне значення для інтервалу очікування, наприклад, 30 секунд.
Якщо критична секція не звільнилася протягом зазначеного часу, то з
дуже великою ймовірністю вона не звільниться ніколи. Має сенс підключити
відладчик і подивитися, що ж коїться в сусідніх нитках. Але на жаль. Ніяких
:: EnterCriticalSectionWithTimeout () в Win32 не передбачено. Натомість є
поле CriticalSectionDefaultTimeout в структурі IMAGE_LOAD_CONFIG_DIRECTORY32,
яке завжди дорівнює нулю і, судячи з усього, не використовується. Зате використовується
ключ в реєстрі "HKLMSYSTEMCurrentControlSetControlSession
ManagerCriticalSectionTimeout ", який за замовчуванням дорівнює 30 діб, і
по закінченню цього часу в системний лог потрапляє рядок "RTL: Enter
Critical Section Timeout (2 minutes) nRTL: Pid.Tid XXXX.YYYY, owner tid
ZZZZnRTL: Re-Waitingn ". До того ж це вірно тільки для систем
WindowsNT/2k/XP і тільки з CheckedBuild. У вас встановлено CheckedBuild? Ні? А
даремно. Ви втрачаєте виняткову можливість побачити цю чудову рядок.
Ну, а які у нас альтернативи? Так, мабуть, тільки
один. Не використовувати API для роботи з критичними секціями. Замість них
написати свої власні. Нехай навіть не такі обточені напильником, як у
Windows NT. Не страшно. Нам це знадобиться тільки в debug-конфігураціях. У
release'ах ми будемо продовжувати використовувати оригінальний API від Microsoft. Для
цього напишемо кілька функцій, повністю сумісних за типами та кількістю
аргументів з "справжнім" API, і додамо # define, як у MFC, для
перевизначення оператора new в debug-конфігураціях.
Лістинг 14. Власна реалізація критичних секцій.
# if defined (_DEBUG) & &! defined (_NO_DEADLOCK_TRACE)
# define DEADLOCK_TIMEOUT 30000
# define CS_DEBUG 1
// Створюємо на льоту подія
для операцій очікування,
// але ніколи його не
звільняємо. Так
зручніше для налагодження
static inline HANDLE _CriticalSectionGetEvent (LPCRITICAL_SECTION pcs)
(
HANDLE ret =
pcs-> LockSemaphore;
if (! ret)
(
HANDLE sem =
:: CreateEvent (NULL, false, false, NULL);
ATLASSERT (sem);
if (! (ret =
(HANDLE):: InterlockedCompareExchangePointer (
& pcs-> LockSemaphore, sem, NULL )))
ret = sem;
else
:: CloseHandle (sem);// Хтось встиг
раніше
)
return ret;
)
// Чекаємо, поки критична
секція не звільниться небудь час очікування
// буде перевищено
static inline VOID _WaitForCriticalSectionDbg (LPCRITICAL_SECTION pcs)
(
HANDLE sem =
_CriticalSectionGetEvent (Pcs);
DWORD dwWait;
do
(
dwWait =
:: WaitForSingleObject (sem, DEADLOCK_TIMEOUT);
if (WAIT_TIMEOUT == dwWait)
(
ATLTRACE ( "Critical
section timeout (% u msec ):"
"tid 0x% 04X
owner tid 0x% 04Xn ", DEADLOCK_TIMEOUT,
:: GetCurrentThreadId (), pcs-> OwningThread);
)
) while (WAIT_TIMEOUT ==
dwWait);
ATLASSERT (WAIT_OBJECT_0 == dwWait);
)
// Виставляємо подія в
активний стан
static inline VOID _UnWaitCriticalSectionDbg (LPCRITICAL_SECTION pcs)
(
HANDLE sem =
_CriticalSectionGetEvent (Pcs);
BOOL b =:: SetEvent (sem);
ATLASSERT (b);
)
// Заполучаем критичну
секцію в своє користування
inline VOID EnterCriticalSectionDbg (LPCRITICAL_SECTION pcs)
(
if
(:: InterlockedIncrement (& pcs-> LockCount))
(
// LockCount став більше нуля.
// Перевіряємо ідентифікатор нитки
if (pcs-> OwningThread ==
(HANDLE):: GetCurrentThreadId ())
(
// Нитка та ж сама. Критична секція
наша.
pcs-> RecursionCount ++;
return;
)
// Критична секція зайнята інший
ниткою.
// Доведеться почекати
_WaitForCriticalSectionDbg (pcs);
)
// Або критична секція була
"вільна",
// або ми дочекалися. Зберігаємо
ідентифікатор поточної нитки.
pcs-> OwningThread =
(HANDLE):: GetCurrentThreadId ();
pcs-> RecursionCount = 1;
)
// Заполучаем критичну
секцію, якщо вона ніким не зайнята
inline BOOL TryEnterCriticalSectionDbg (LPCRITICAL_SECTION pcs)
(
if (-1L ==
:: InterlockedCompareExchange (& pcs-> LockCount, 0, -1))
(
// Це перше звернення до критичної
секції
pcs-> OwningThread =
(HANDLE):: GetCurrentThreadId ();
pcs-> RecursionCount = 1;
)
else if (pcs-> OwningThread
== (HANDLE):: GetCurrentThreadId ())
(
// Це не перше звернення, але з тієї ж
нитки
:: InterlockedIncrement (& pcs-> LockCount);
pcs-> RecursionCount ++;
)
else
return FALSE;// Критична секція
зайнята іншою ниткою
return TRUE;
)
// Звільняємо критичну секцію
inline VOID LeaveCriticalSectionDbg (LPCRITICAL_SECTION pcs)
(
// Перевіряємо, щоб ідентифікатор поточної
нитки збігався
// з ідентифікатором нитки-власника.
// Якщо це не так, швидше за все ми маємо
справу з помилкою
ATLASSERT (pcs-> OwningThread ==
(HANDLE):: GetCurrentThreadId ());
if (- pcs-> RecursionCount)
(
// Не останній виклик з цієї нитки.
// Зменшуємо значення поля LockCount
:: InterlockedDecrement (& pcs-> LockCount);
)
else
(
// Останній дзвінок. Потрібно
"розбудити" яку-небудь
// з очікують ниток, якщо такі
є
ATLASSERT (NULL! = pcs-> OwningThread);
pcs-> OwningThread = NULL;
if
(:: InterlockedDecrement (& pcs-> LockCount)> = 0)
(
// Є, як мінімум, один очікує нитка
_UnWaitCriticalSectionDbg (Pcs);
)
)
)
// засвідчує, що:: EnterCriticalSection () була викликана
// до виклику цього методу
inline BOOL CheckCriticalSection (LPCRITICAL_SECTION pcs)
(
return pcs-> LockCount> =
0
& &
pcs-> OwningThread == (HANDLE):: GetCurrentThreadId ();
)
// перевизначають все
функції для роботи з критичними секціями.
// Визначення класу CLock
повинно бути після цих рядків
# define EnterCriticalSection EnterCriticalSectionDbg
# define TryEnterCriticalSection TryEnterCriticalSectionDbg
# define
LeaveCriticalSection LeaveCriticalSectionDbg
# endif
Ну і заразом додамо ще один метод в наш клас Clock
(лістинг 15).
Лістинг 15. Клас CLock з новим методом.
class CLock
(
friend class CScopeLock;
CRITICAL_SECTION m_CS;
public:
void Init () (
:: InitializeCriticalSection (& m_CS);)
void Term () (
:: DeleteCriticalSection (& m_CS);)
void Lock () (
:: EnterCriticalSection (& m_CS);)
BOOL TryLock () (return
:: TryEnterCriticalSection (& m_CS);)
void Unlock () (
:: LeaveCriticalSection (& m_CS);)
BOOL Check () (return
CheckCriticalSection (& m_CS);)
);
Використовувати метод Check () в release-конфігурація не
стоїть, можливо, що в майбутньому, в якій-небудь Windows64, структура
RTL_CRITICAL_SECTION зміниться, і результат такої перевірки буде не визначений.
Так що йому саме місце "жити" всередині усіляких ASSERT'ов.
Отже, що ми маємо? Ми маємо перевірку на зайвий виклик
:: LeaveCriticalSection () і ту ж трасування для блокувань. Не так вже й багато.
Особливо якщо трасування про блокування має місце, а ось нитка, яка забула
звільнити критичну секцію, давно завершилася. Як бути? Вірніше, що б ще
придумати, щоб помилку простіше було виявити? Як мінімум, прикрутити сюди
__LINE__ І __FILE__, константи, що відповідають поточному рядку й імені файлу на
момент компіляції цього методу.
VOID
EnterCriticalSectionDbg (LPCRITICAL_SECTION pcs
, int nLine = __LINE__, azFile = __FILE__);
Компіліруем, запускаємо ... Результат дивовижний. Хоча
правильний. Компілятор чесно підставив номер рядка та ім'я файлу,
відповідні початку нашої EnterCriticalSectionDbg (). Так що доведеться
попотіти трохи більше. __LINE__ І __FILE__ потрібно вставити в # define'и, тоді
ми отримаємо дійсні номер рядка та ім'я вихідного файлу. Тепер питання,
куди ж зберегти ці параметри для подальшого використання? Причому хочеться
залишити за собою можливість виклику стандартних функцій API поряд з нашими
власними? На допомогу приходить C + +: просто створимо свою структуру,
успадкувавши її від RTL_CRITICAL_SECTION (лістинг 16).
Лістинг 16. Реалізація критичних секцій з
збереженням рядку й імені файлу.
# if defined (_DEBUG) & &! defined (_NO_DEADLOCK_TRACE)
# define DEADLOCK_TIMEOUT 30000
# define CS_DEBUG 2
// Наша структура замість CRITICAL_SECTION
struct CRITICAL_SECTION_DBG: public CRITICAL_SECTION
(
// Додаткові поля
int
m_nLine;
LPCSTR
m_azFile;
);
typedef struct CRITICAL_SECTION_DBG * LPCRITICAL_SECTION_DBG;
// Створюємо на льоту подія
для операцій очікування,
// але ніколи його не
звільняємо. Так
зручніше для налагодження.
static inline HANDLE _CriticalSectionGetEvent (LPCRITICAL_SECTION pcs)
(
HANDLE ret =
pcs-> LockSemaphore;
if (! ret)
(
HANDLE sem =
:: CreateEvent (NULL, false, false, NULL);
ATLASSERT (sem);
if (! (ret =
(HANDLE):: InterlockedCompareExchangePointer (
& pcs-> LockSemaphore, sem, NULL )))
ret = sem;
else
:: CloseHandle (sem);// Хтось встиг
раніше
)
return ret;
)
// Чекаємо, поки критична
секція не звільниться небудь час очікування
// буде перевищено
static inline VOID _WaitForCriticalSectionDbg (LPCRITICAL_SECTION_DBG
pcs
, int nLine, LPCSTR azFile)
(
HANDLE sem =
_CriticalSectionGetEvent (Pcs);
DWORD dwWait;
do
(
dwWait =
:: WaitForSingleObject (sem, DEADLOCK_TIMEOUT);
if (WAIT_TIMEOUT == dwWait)
(
ATLTRACE ( "Critical
section timeout (% u msec ):"
"tid 0x% 04X owner
tid 0x% 04Xn "
"Owner lock from
% hs line% u, waiter% hs line% un "
, DEADLOCK_TIMEOUT
,
:: GetCurrentThreadId (), pcs-> OwningThread
, pcs-> m_azFile,
pcs-> m_nLine, azFile, nLine);
)
) while (WAIT_TIMEOUT ==
dwWait);
ATLASSERT (WAIT_OBJECT_0 ==
dwWait);
)
// Виставляємо подія в активний стан
static inline VOID _UnWaitCriticalSectionDbg (LPCRITICAL_SECTION pcs)
(
HANDLE sem =
_CriticalSectionGetEvent (Pcs);
BOOL b =:: SetEvent (sem);
ATLASSERT (b);
)
// Ініціалізіруем критичну
секцію.
inline VOID InitializeCriticalSectionDbg (LPCRITICAL_SECTION_DBG pcs)
(
// Нехай система заповнить свої поля
InitializeCriticalSection (pcs);
// Заповнюємо наші поля
pcs-> m_nLine = 0;
pcs-> m_azFile = NULL;
)
// Звільняємо ресурси, які займає
критичною секцією
inline VOID DeleteCriticalSectionDbg (LPCRITICAL_SECTION_DBG pcs)
(
// Перевіряємо, щоб не було вилучень
"захоплених" критичних секцій
ATLASSERT (0 == pcs-> m_nLine & &
NULL == pcs-> m_azFile);
// Останнє доробить система
DeleteCriticalSection (pcs);
)
// Заполучаем критичну
секцію в своє користування
inline VOID EnterCriticalSectionDbg (LPCRITICAL_SECTION_DBG pcs
, int nLine, LPSTR azFile)
(
if
(:: InterlockedIncrement (& pcs-> LockCount))
(
// LockCount став більше нуля.
// Перевіряємо ідентифікатор нитки
if (pcs-> OwningThread ==
(HANDLE):: GetCurrentThreadId ())
(
// Нитка та ж сама. Критична секція
наша.
// Ніяких додаткових дій не
виробляємо.
// Це не зовсім вірно, тому що
можливо, що непарний
// виклик:: LeaveCriticalSection () був
зроблений на n-ному заході,
// і це доведеться відловлювати вручну,
але реалізація
// стека для __LINE__ і __FILE__
зробить нашу систему
// більш громіздкою. Якщо це дійсно
необхідно,
// ви завжди можете зробити це
самостійно
pcs-> RecursionCount ++;
return;
)
// Критична секція зайнята інший
ниткою.
// Доведеться почекати
_WaitForCriticalSectionDbg (pcs, nLine,
azFile);
)
// Або критична секція була
"вільна",
// або ми дочекалися. Зберігаємо
ідентифікатор поточної нитки.
pcs-> OwningThread =
(HANDLE):: GetCurrentThreadId ();
pcs-> RecursionCount = 1;
pcs-> m_nLine = nLine;
pcs-> m_azFile = azFile;
)
// Заполучаем критичну
секцію, якщо вона ніким не зайнята
inline BOOL TryEnterCriticalSectionDbg (LPCRITICAL_SECTION_DBG pcs
, int nLine, LPSTR azFile)
(
if (-1L ==
:: InterlockedCompareExchange (& pcs-> LockCount, 0, -1))
(
// Це перше звернення до критичної
секції
pcs-> OwningThread =
(HANDLE):: GetCurrentThreadId ();
pcs-> RecursionCount = 1;
pcs-> m_nLine = nLine;
pcs-> m_azFile = azFile;
)
else if (pcs-> OwningThread
== (HANDLE):: GetCurrentThreadId ())
(
// Це не перше звернення, але з тієї ж
нитки
:: InterlockedIncrement (& pcs-> LockCount);
pcs-> RecursionCount ++;
)
else
return FALSE;// Критична секція
зайнята іншою ниткою
return TRUE;
)
// Звільняємо критичну секцію
inline VOID LeaveCriticalSectionDbg (LPCRITICAL_SECTION_DBG pcs)
(
// Перевіряємо, щоб ідентифікатор поточної
нитки з?? впадав
// з ідентифікатором нитки-влядельца.
// Якщо це не так, швидше за все ми маємо
справу з помилкою
ATLASSERT (pcs-> OwningThread ==
(HANDLE):: GetCurrentThreadId ());
if (- pcs-> RecursionCount)
(
// Не останній виклик з цієї нитки.
// Зменшуємо значення поля LockCount
:: InterlockedDecrement (& pcs-> LockCount);
)
else
(
// Останній дзвінок. Потрібно
"розбудити" яку-небудь
// з очікують ниток, якщо такі
є
ATLASSERT (NULL! = pcs-> OwningThread);
pcs-> OwningThread = NULL;
pcs-> m_nLine = 0;
pcs-> m_azFile = NULL;
if
(:: InterlockedDecrement (& pcs-> LockCount)> = 0)
(
// Є, як мінімум, один очікує нитка
_UnWaitCriticalSectionDbg (pcs);
)
)
)
// засвідчує, що:: EnterCriticalSection () була викликана
// до виклику цього методу
inline BOOL CheckCriticalSection (LPCRITICAL_SECTION pcs)
(
return pcs-> LockCount> =
0
& &
pcs-> OwningThread == (HANDLE):: GetCurrentThreadId ();
)
// перевизначають все
функції для роботи з критичними секціями.
// Визначення класу CLock
повинно бути після цих рядків
# define InitializeCriticalSection InitializeCriticalSectionDbg
# define InitializeCriticalSectionAndSpinCount (pcs, c)
InitializeCriticalSectionDbg (pcs)
# define DeleteCriticalSection DeleteCriticalSectionDbg
# define EnterCriticalSection (pcs) EnterCriticalSectionDbg (pcs,
__LINE__, __FILE__)
# define TryEnterCriticalSection (pcs)
TryEnterCriticalSectionDbg (pcs, __LINE__, __FILE__)
# define LeaveCriticalSection LeaveCriticalSectionDbg
# define CRITICAL_SECTION CRITICAL_SECTION_DBG
# define LPCRITICAL_SECTION LPCRITICAL_SECTION_DBG
# define PCRITICAL_SECTION PCRITICAL_SECTION_DBG
# endif
Наводимо наші класи у відповідність (лістинг +17).
Лістинг 17. Класи CLock і CScopeLock, варіант для
налагодження.
class CLock
(
friend class CScopeLock;
CRITICAL_SECTION m_CS;
public:
void Init () (
:: InitializeCriticalSection (& m_CS);)
void Term () (
:: DeleteCriticalSection (& m_CS);)
# if defined (CS_DEBUG)
BOOL Check () (return
CheckCriticalSection (& m_CS);)
# endif
# if CS_DEBUG> 1
void Lock (int nLine, LPSTR
azFile) (EnterCriticalSectionDbg (& m_CS, nLine, azFile);)
BOOL TryLock (int nLine, LPSTR
azFile) (return TryEnterCriticalSectionDbg (& m_CS, nLine, azFile);)
# else
void Lock () (
:: EnterCriticalSection (& m_CS);)
BOOL TryLock () (return
:: TryEnterCriticalSection (& m_CS);)
# endif
void Unlock () (
:: LeaveCriticalSection (& m_CS);)
);
class CScopeLock
(
LPCRITICAL_SECTION m_pCS;
public:
# if CS_DEBUG> 1
CScopeLock (LPCRITICAL_SECTION
pCS, int nLine, LPSTR azFile): m_pCS (pCS) (Lock (nLine, azFile);)
CScopeLock (CLock & lock,
int nLine, LPSTR azFile): m_pCS (& lock.m_CS) (Lock (nLine, azFile);)
void Lock (int nLine, LPSTR
azFile) (EnterCriticalSectionDbg (m_pCS, nLine, azFile);)
# else
CScopeLock (LPCRITICAL_SECTION
pCS): m_pCS (pCS) (Lock ();)
CScopeLock (CLock & lock):
m_pCS (& lock.m_CS) (Lock ();)
void Lock () (:: EnterCriticalSection (m_pCS);
)
# endif
~ CScopeLock () (Unlock ();)
void Unlock () (
:: LeaveCriticalSection (m_pCS);)
);
# if CS_DEBUG> 1
# define Lock () Lock (__LINE__, __FILE__)
# define TryLock () TryLock (__LINE__, __FILE__)
# define lock (cs) lock (cs, __LINE__, __FILE__)
# endif
На жаль, довелося навіть перевизначити CScopeLock
lock (cs), причому жорстко прив'язатися до імені змінної. Не варто говорити про
те, що напевно вийшов конфлікт імен - все-таки Lock досить популярне
назва для методу. Такий код не буде збиратися, наприклад, з популярною
бібліотекою ATL. Тут є два способи. Перейменувати методи Lock () і TryLock ()
у що-небудь більш унікальне, або перейменувати Lock () в ATL:
// StdAfx.h
//. ..
# define Lock ATLLock
# include
//. ..
Сме
Лістинг 1. Псевдокод
RtlInitializeCriticalSection з ntdll.dll
Лістинг
9. Пропущений дзвінок:: LeaveCriticalSection ().