Mutex lockolás Windowson

Clipper, CCC

Az az érdekesség van, hogy a thread_mutex_lock és unlock Linuxon remekül működik egy programomban, szépen nullát adnak mindig vissza. Windowson viszont az unlock 1-et ad vissza, ez az EPERM üzenet, és azt jelenti, hogy Operation not permitted, a doksi szerint ez azt jelenti, hogy a hívó szál nem birtokolja a mutexet. De akkor miért nem panaszkodott a mutex_lock? Van valakinek ötlete? A program amúgy jól tűnik működni, látszólag nem akadnak össze a szálak.

w

  • 4799 megtekintés

( mrev | 2007. 04. 07., szo – 09:36 )

Van itt pár kérdés amivel csak a jövő héten tudok foglalkozni.

Ami az unlockot illeti:

void _clp_thread_mutex_unlock(int argno)
{
CCC_PROLOG("thread_mutex_unlock",1);
HANDLE mutex=(HANDLE)_parp(1);
_retni( ReleaseMutex(mutex) );
CCC_EPILOG();
}

Gondolom a ReleaseMutex ad vissza 1-et. Talán nem az a szál unlockol, mint amelyik lockolt. Úgy rémlik Linuxon ilyenkor is megtörténik az unlock, ami attól még logikai hiba, és nem kell rá programot alapozni.

--
CCC3

Megvan az egységesítés. (Már ami visszatérési értékeket illeti. A Linux változatlan maradt, a Windows változott, a pthread API mintájára.)

Észrevettem viszont (valószínűleg tudtam róla, csak időközben elfelejtettem), hogy Windowson a mutex lockolás olyan, mintha Linuxon rekurzív mutexet használnánk. Azaz,

Linuxon:

thread_mutex_lock(mutex)
thread_mutex_lock(mutex) //deadlock

Windowson:

thread_mutex_lock(mutex) //egyszeresen lockolva
thread_mutex_lock(mutex) //kétszeresen lockolva
...
thread_mutex_unlock(mutex) //még egyszeresen lockolva
thread_mutex_unlock(mutex) //elengedte

Lehetne vesződni a kiegyenlítéssel, vagy hogy opció legyen a mutex típusa, csak nem tudom, megéri-e. Más UNIX-okon nincs rekurzív mutex. UNIX-on is Windowson is saját számlálót kellene vezetni, márpedig ennek a lehető leggyorsabbnak kéne lennie. Ezzel az eltéréssel azt lehet mondani, hogy a Linuxon tesztelt program jó Windowson is, ami nekem eddig elég volt.

--
CCC3