I changed some values in some threaded code from using constants to looking up the values from a database and I have been getting errors all the time, that values which are present in the database are missed by the sequential scan. I have been getting some Externa SIGSEGVs a lot.

I am not sure if the database library code is faulty or looking up the values in a thread is the problem

The database lookup code is in a data module running in the main thread. Do I have to use a critical section in data module containing the threads to the database lookup?

The threads are run in a different module from the one with database lookup. Should the CriticalSection be in DataModule containing the threads or in the DataModule with the lookup?

Do the other forms running in the main thread also require the critical section, or is that only for the stuff in the thread?

ie.

EnterCriticalSection(ModuleWithThreads.CriticalSection)
LookupDatabaseCode;
LeaveCriticalSection(ModuleWithThreads.CriticalSection);

I changed some values in some threaded code from using constants to looking up the values from a database and I have been getting errors all the time, that values which are present in the database are missed by the sequential scan. I have been getting some Externa SIGSEGVs a lot.

The minimum requirement for multithreaded db access is to use a separate db connection for every thread and transaction isolation.

I am not sure if the database library code is faulty or looking up the values in a thread is the problem

Some database client libraries have problems with multithreading or have threadsafe versions (fe. libmysql.dll is not threadsafe in the standard version).

The database lookup code is in a data module running in the main thread. Do I have to use a critical section in data module containing the threads to the database lookup?

No. That is trying to solve the problem in the wrong place.

Ludo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111003/c9403cde/attachment.html>

2011/10/2 Frank Church

EnterCriticalSection(ModuleWithThreads.CriticalSection) LookupDatabaseCode; LeaveCriticalSection(ModuleWithThreads.CriticalSection);

Don't forget use try..finally..end

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111003/6643d61a/attachment.html>

2011/10/3 Ludo Brands

If I put a TCP component such as an Indy http component on that data module, and get all the lookups to be done over the http socket, is that likely to fix the problem, rather than calling the database lookup code in the data module directly from the threads?

The minimum requirement for multithreaded db access is to use a separate db connection for every thread and transaction isolation.

I am not sure if the database library code is faulty or looking up the values in a thread is the problem

Some database client libraries have problems with multithreading or have threadsafe versions (fe. libmysql.dll is not threadsafe in the standard version).

The database lookup code is in a data module running in the main thread. Do I have to use a critical section in data module containing the threads to the database lookup?

No. That is trying to solve the problem in the wrong place.

Ludo

If I put a TCP component such as an Indy http component on that data module, and get all the lookups to be done over the http socket, is that likely to fix the problem, rather than calling the database lookup code in the data module directly from the threads?

You mean you have a 2nd path to your database over http? As long as you don't use the same database connection (session) from the different threads and are sure there are no transaction isolation issues you can use whatever communication protocol you like. Seems complicating things though. Why don't you write a data lookup class in your data module that uses it's own Txxxconnection,TSQLTransaction and TSqlQuery and have each thread use its own instance? Destroy after use or, when frequent data updates are needed, give it a DisConnect method so that the number of sessions remains reasonable. If you have a lot of threads and the number of simultanuous database sessions is an issue, then write one lookup procedure using a criticial section but, again, using its own database connection: enter criticial section, connect to database, run sql, retrieve data, disconnect, exit critical section.

Ludo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111003/796ceecc/attachment.html>

2011/10/3 Ludo Brands

I am now using a separate TConnection for the threaded code and now all the values are found if the database lookup code executes, but it seems that the database lookup is not called all the time, and this may be due to some of the threads not executing properly.

I will make some more tests to see where the other problems might be