As we have in our programs some global arrays for administration of objects and these can be called by the garbage collector I have inserted some code for making thread safe these parts.
The first time I tried with EnterCriticalSection (@slpCriticalSection) and LeaveCriticalSection (@slpCriticalSection) as it would have been done in older C program.
But I got randomly complete program locking without knowing the reason. Then I tried with incapsulation of these array access with the following code and it seems to resolve the issues:
BEGIN LOCK __golockacsutyobj
....
END LOCK
GLOBAL ____golockacsutyobj := OBJECT{} AS OBJECT
Arne
Making programs partially threadsafe (Garbage Collector Part 2)
-
ArneOrtlinghaus
- Posts: 384
- Joined: Tue Nov 10, 2015 7:48 am
- Location: Italy
-
ArneOrtlinghaus
- Posts: 384
- Joined: Tue Nov 10, 2015 7:48 am
- Location: Italy
Making programs partially threadsafe (Garbage Collector Part 2)
My initially problems with random crashs within the ODBC driver seem to be resolved:
- Instead of closing the ODBC statement handles in the destructor the statement handles are saved within a global collection, taking only the ODBC handle and not the statement itself.
- The statement object itself can be destroyed by the Garbage Collector.
- When opening a new statement the global collection is checked on open statement handles. If yes, these statement handles are closed with the correct ODBC functions.
- This way all ODBC work that is not threadsafe, is handled in the main thread and it is not important if the statement objects have been closed by the programmer or not.
It is impressing how quickly the Dotnet Garbage Collector is working. In my tests it was not so easy to generate "Maximum cursor number reached" errors from the database because the GC disposed very quickly unused objects while the program created new objects.
- Instead of closing the ODBC statement handles in the destructor the statement handles are saved within a global collection, taking only the ODBC handle and not the statement itself.
- The statement object itself can be destroyed by the Garbage Collector.
- When opening a new statement the global collection is checked on open statement handles. If yes, these statement handles are closed with the correct ODBC functions.
- This way all ODBC work that is not threadsafe, is handled in the main thread and it is not important if the statement objects have been closed by the programmer or not.
It is impressing how quickly the Dotnet Garbage Collector is working. In my tests it was not so easy to generate "Maximum cursor number reached" errors from the database because the GC disposed very quickly unused objects while the program created new objects.