[VC6] Verschil Debug / Release build

[Verwijderd]

Ik heb een applicatie via VC6 (zonder service packs) gecompileerd en gelinked, welke wel goed werkt als Debug build, maar niet als Release. Het probleem is dat de Release build blijft wachten op een semaphore die door een externe applicatie wordt vrijgegeven. De Debug build merkt wel dat deze semaphore wordt vrijgegeven en gaat vrolijk verder. In hoeverre kan er verschil zitten tussen Debug en Release builds? Bij deze de relevante code van beide applicaties, misschien dat er in de code wat fout zit, maar aangezien de Debug werkt, vraag ik me af of dit het probleem is.

server (LabWindows) wacht tot semaphore "Kilnlog Server Memory Semaphore" wordt vrijgegeven, zet dan een stuk geheugen apart en geeft semaphore "Kilnlog Client Memory Semaphore" vrij:

C:

#include <windows.h>
HANDLE hSemClientMem, hSemServerMem;
int threadPool;


void start (void) {
  createSemaphores();

  CmtNewThreadPool (2, &threadPool);
  CmtScheduleThreadPoolFunction (threadPool, threadFunctionMem, NULL, NULL);
}

void createSemaphores (void) {
  hSemServerMem = CreateSemaphore (NULL, 1, 1, "Kilnlog Server Memory Semaphore");
  hSemClientMem = CreateSemaphore (NULL, 1, 1, "Kilnlog Client Memory Semaphore");
}

int CVICALLBACK threadFunctionMem (void *functionData) {
  while (endLog==0) {
    WaitForSingleObject (hSemServerMem, INFINITE);

    if (endLog==0) {
      // Zet geheugen klaar
      ReleaseSemaphore (hSemClientMem, 1, NULL);
    }
  }
}

client (VC6) geeft periodiek opdracht aan de server om geheugen apart te zetten, als het geheugen apart gezet is, en dus de semaphore "Kilnlog Client Memory Semaphore" vrijgegeven is, wordt wat met het geheugen gedaan en wordt de semaphore "Kilnlog Server Client Memory" weer vrijgegeven, zodat het geheugen opnieuw apart gezet wordt, etc. Normaal zit er een timer functie tussen en alle handles worden netjes opgeruimd als de applicatie wordt afgesloten, maar dat is nu even niet van toepassing:

C:

#include <windows.h>

HANDLE  hSemServerMem, hSemClientMem;

void createSemaphores (void) {
  hSemServerMem = CreateSemaphore (NULL, 1, 1, "Kilnlog Server Memory Semaphore");
  hSemClientMem = CreateSemaphore (NULL, 1, 1, "Kilnlog Client Memory Semaphore");
}

int main (void) {
  createSemaphores();
  signalServer();
  while (checkSharedMem()) {
    waitServer();
    // Doe wat

    signalServer();
  }
}

bool waitServer (void) {
  switch (WaitForSingleObject (hSemClientMem, SERVER_TIMEOUT)) {
    case WAIT_OBJECT_0:
      // Alles goed
      break;

    case WAIT_TIMEOUT:
      // Fout
      break;
  }
}

void signalServer (void) {
  ReleaseSemaphore (hSemServerMem, 1, NULL);
}

Zit er een enorme fout in deze code of hoe komt het verschil Debug/Release?

[ Voor 11% gewijzigd door Verwijderd op 05-05-2004 21:19 ]

[pjvandesande]

Verwijderd schreef op 05 mei 2004 @ 16:36:
Ik heb een applicatie via VC6 (zonder service packs)

Het installeren van de laatste service packs lijkt me niet meer dan logisch. Maar verder heb ik hier absoluut nog nooit last van gehad of gehoort.

Installeer de service packs toch is.

[farlane]

Als je verschil hebt tussen het gedrag in release en debug build kan het zijn dat :

- je een initialisatie probleem hebt
- je een timing probleem hebt
- een bug hebt gevonden
- all of the above
- none of the above

[MSalters]

Gezien het woord "thread" verdenk ik endLog, dat lijkt eerder op een Win32 Event. Zo mist er ogenschijnlijk een mutex (Win32: CriticalSection)

[curry684]

MSalters schreef op 05 mei 2004 @ 21:58:
Gezien het woord "thread" verdenk ik endLog, dat lijkt eerder op een Win32 Event. Zo mist er ogenschijnlijk een mutex (Win32: CriticalSection)

Win32 heeft zowel mutexes als critical sections. De Critical Section is een process-local ultrathin wrappertje met simpele API, en de Mutex is een global named of unnamed kernel object met volledige support voor de hele reeks WaitFor... functies uit de Win32 API.

Waarom gebruik je trouwens in godesnaam binary semaphores ipv mutexen?

[ Voor 8% gewijzigd door curry684 op 05-05-2004 22:06 ]

[Verwijderd]

MSalters schreef op 05 mei 2004 @ 21:58:
Gezien het woord "thread" verdenk ik endLog, dat lijkt eerder op een Win32 Event. Zo mist er ogenschijnlijk een mutex (Win32: CriticalSection)

endLog is een variabele die ik zelf binnen het programma gebruik. Heb het niet opgenomen in deze code omdat er dan wat extra functies bij komen, maar het komt erop neer dat als de client af wordt gesloten, de threads blijven wachten (WaitForSingleObject (..., INFINITE). In een functie, welke wordt aangeroepen bij het afsluiten van de applicatie wordt eerst endLog op 1 gezet en daarna alle semaphores vrijgegeven. Zo wordt niet in sommige functies weer op reactie van de client gewacht.

Ik ben aan het nakijken of ik ergens een initialisatie niet goed heb staan, maar in het debug scherm zie ik totaal geen foutmeldingen of waarschuwingen komen, alle threads en de applicatie eindigt ook netjes met 0.

Waarom gebruik je trouwens in godesnaam binary semaphores ipv mutexen?

De mutex wilde alleen werken binnen de eigen applicatie; als ik de mutex van de externe applicatie vrijgeef, merkt deze hier niets van.. Ok misschien beter om dat even uit te zoeken, maar alle andere semaphoren werken goed en het was nogal makkelijk een extra semaphore te maken ipv een enkele mutex ertussen te doen.

[ Voor 20% gewijzigd door Verwijderd op 05-05-2004 22:15 ]

[curry684]

Verwijderd schreef op 05 mei 2004 @ 22:11:
[...]
endLog is een variabele die ik zelf binnen het programma gebruik. Heb het niet opgenomen in deze code omdat er dan wat extra functies bij komen, maar het komt erop neer dat als de client af wordt gesloten, de threads blijven wachten (WaitForSingleObject (..., INFINITE). In een functie, welke wordt aangeroepen bij het afsluiten van de applicatie wordt eerst endLog op 1 gezet en daarna alle semaphores vrijgegeven. Zo wordt niet in sommige functies weer op reactie van de client gewacht.

Ik ben aan het nakijken of ik ergens een initialisatie niet goed heb staan, maar in het debug scherm zie ik totaal geen foutmeldingen of waarschuwingen komen, alle threads en de applicatie eindigt ook netjes met 0.

Als je simpelweg een signaal van A naar B wil sturen dien je daar middels CreateEvent een event object voor aan te maken: die is threadsafe en kun je vervolgens in WaitForMultipleObjects met INFINITE gebruiken samen met de mutex, zodat je weet welke van de 2 signaled is.

De mutex wilde alleen werken binnen de eigen applicatie; als ik de mutex van de externe applicatie vrijgeef, merkt deze hier niets van.. Ok misschien beter om dat even uit te zoeken, maar alle andere semaphoren werken goed en het was nogal makkelijk een extra semaphore te maken ipv een enkele mutex ertussen te doen.

Een semaphore is (marginaal) langzamer dan een mutex, maar vooral tig keer onleesbaarder in je code: je moet je continu afvragen in de code hoe groot de semaphore is. Een mutex is per definitie binair en dus helder in dat aspect. De API is verder hetzelfde dus zou gewoon moeten werken.

[Verwijderd]

Bedankt, ik heb CreateEvent gebruikt en dat volstaat voor alles wat ik nodig heb. Release heeft nu geen kuren meer, maar ik heb de code grotendeels herschreven dus of het nou door een foute initializatie kwam weet ik nog niet, maar het uitzoeken of het een initializatie- of timing-probleem was zoals farlane zei gaat me te lang duren als het niet gedebugd kan worden. Bedankt curry684 voor de tip.

[curry684]

Verwijderd schreef op 06 mei 2004 @ 01:17:
Bedankt, ik heb CreateEvent gebruikt en dat volstaat voor alles wat ik nodig heb. Release heeft nu geen kuren meer, maar ik heb de code grotendeels herschreven dus of het nou door een foute initializatie kwam weet ik nog niet, maar het uitzoeken of het een initializatie- of timing-probleem was zoals farlane zei gaat me te lang duren als het niet gedebugd kan worden. Bedankt curry684 voor de tip.

No problem Zolang je je synchronizatie maar goed dichttimmert is de timing altijd okee, en je had gewoon een paar unsafe accesses.

[MSalters]

curry684 schreef op 05 mei 2004 @ 22:05:
[...]
Win32 heeft zowel mutexes als critical sections. De Critical Section is een process-local ultrathin wrappertje met simpele API, en de Mutex is een global named of unnamed kernel object met volledige support voor de hele reeks WaitFor... functies uit de Win32 API.

Om de verwarring uit de wereld te helpen:
In de informatica heb je critical sections en mutexes. Een critical section is daar feitelijk een mutex met maar 1 locking punt - voorafgaand aan code die maar door een thread tegelijk kan worden gebruikt. Een mutex kan alle shared resources beschermen, maar een resource die op meerdere punten wordt gebruikt heeft dus meerdere mutex lock punten.

In Win32 heb je ook CriticalSections, maar dat zijn gewoon mutexen uit de Informatica. Het enige verschil met een normale win32 Mutex is dat een win32 critical section inderdaad process-local is. Win32 heeft geen echte critical sections.