Are multiple critical sections allowed in form or data module?

e.g. I have different datasets each with its own connection and queries that threads need to lookup data from.

Is it acceptable to have additional TCriticalSections on the form?

Yes.
I hope you are aware that all code accessing the LCL must run in the main thread.

Mattias

Can you explain this?
Do you mean that TCriticalSection is part of the LCL and shouldn't be run from within a thread, or that code within the thread or the critical section must not run code accessing the LCL?

How is it determined whether a piece of code runs within the LCL or not?

All LCL code that deals with Application, TControl or widget handles is not thread safe and should only be accessed by the main thread. When another thread needs to access these LCL parts it should do it via the main thread, for example via Synchronize.

How is it determined whether a piece of code runs within the LCL or not?

if GetCurrentThreadID=MainThreadID then

Mattias

[...] The LCL is not reentrant.

Most LCL code is reentrant. An event can trigger an event. On of the few exceptions is destroying a control. That's why there is Application.ReleaseComponent.

[...]

Mattias

A critical section blocks all code, that wants to enter the same (occupied) critical section, until the current owner left the critical section. You can have any number of critical section objects, and they can be used in a nested manor - at the risk of deadlocks.

Do you mean that TCriticalSection is part of the LCL and shouldn't be run from within a thread, or that code within the thread or the critical section must not run code accessing the LCL?

The LCL is not reentrant. All code accessing the LCL should run in the main thread (see Synchronize...), not in other threads.

How is it determined whether a piece of code runs within the LCL or not?

Wrong question :-(

Whenever your code accesses a procedure or object of the LCL, that code should not reside (and execute) in an thread. A thread should provide a (callback) method instead, which contains such code, and make that method execute in the main thread (see Synchronize...).

I'm not sure how some code can determine, whether it runs in the main thread.

DoDi

Only within the context of an single thread.

This was acceptable on traditional single-CPU/core machines, but nowadays non-visual components, and also parts of a GUI, should be manageable in different (dedicated) threads.

DoDi

It's not so on Unix. X-Windows is definitely not thread-safe.

I also have not seen any claims from Microsoft that the GDI controls are thread-safe, and according to

http://stackoverflow.com/questions/2798812/net-controls-why-arent-all-calls-thread-safe

it is simply not thread safe, some exceptions aside.

The argument put forward there is a sane one: only the programmer can meaningfully decide on the granularity of the needed marshalling. A framework never can do that.

Michael.

True, widgetsets typically are not threadsafe, that's not the problem. Remember an recent thread, where e.g. a progress bar could be attached to and served by an thread, independently from the main application GUI. The same for data modules...

DoDi

Frank Church wrote

Are multiple critical sections allowed in form or data module?

I don't understand your concern.

A DataModule is a way to organize the makeup and dependance of objects (so strictly a question of data in memory).

A CriticalSection is a way to organize the instruction flow.

So they have close to no connection.

(In short: Yes)

-Michael

TCriticalSection is obviously done to be used in Thread.

How is it determined whether a piece of code runs within the LCL or not?

The documentation on this is rather poor. (E.g. the "Thread-Safety" of Tlist has recently been discussed.)

In fact the help for any LCL and RTL function should say how it can be used regarding threads.

It is known that any function that accesses the GUI can only be called by the main thread. You might get a runtime error when violating this rule, but there is no purposeful

Mattias Gaertner wrote

All LCL code that deals with Application, ... is not thread safe and should only be accessed by the main thread.

Hmmm.

Application.QueuAsyncCall() is obviously created to be called by a thread.

So it's necessary to read the documentation to be sure.

-Michael

I understand his question as "How to find out whether a function in the RTL is allowed to be called by a thread? "

Here only the documentation can help. When it is not elaborated enough you need good intuition.

-Michael

Hans-Peter Diettrich wrote

The LCL is not reentrant. All code accessing the LCL should run in the main thread (see Synchronize...), not in other threads.

Not true in this intensity.

There are functions in the LCL especially doe not be called by worker Threads, and there are certain functions in the LCL that can be called by the main threads and by worker thread.

Moreover there are complicated cases (Like TList in the RTL the functions of which are only "thread save" when the threads don't use the same instance, while TThreadList is documented to be always thread save.)

-Michael

In a single threadded application only recursive functions can have reentrancy problems.

As nearly all user code is done as an event (callback) from the LCL the LCL is always called in a recursive way and thus is is bound to be reentrant-save to a certain extent.

-Michael

Michael Van Canneyt wrote

It's not so on Unix. X-Windows is definitely not thread-safe.

Of course "in general" this is correct.

But I understand that it should be possible that an application (using additional threads) creates more than one "Main Frame" by attaching to a new "instance" of the Widget set and thus - regarding the GUI - acts as multiple applications, (But quite obviously the LCL does not support this, as it uses some global variables to manage the "Application".)

-Michael

I don't think that the LCL should support this.
It adds another layer of complexity for no good reason at all, with questionable end-results.

See the link I posted for a good explanation of why this is a bad idea.

Michael.

Michael Van Canneyt wrote

It's not so on Unix. X-Windows is definitely not thread-safe.

And neither is OpenGL (and afaik Direct X also)

On 10/10/2011 10:23 AM, Michael Schnell wrote:
type:

There are functions in the LCL especially done be called by worker Threads,...

-Michael

Type: LCL

-Michael

I don't think that the LCL should support this.

I did not want to suggest that it should (IMHO it would be "nice" to have this as a special Application type, but it's (a) not easy to do and (b) quite low priority. I in fact do have a (Delphi) application that would benefit of allowing a multi-threaded GUI on a multi-core machine. But I recon that this is a very uncommon case.)

It adds another layer of complexity for no good reason at all, with questionable end-results.

I fully agree.

-Michael

So you claim that nobody should use Application.QueuAsyncCall() ?!?!?!

IMHO same is a very powerful and portable and thus indispensable way to do a notification to the main frame and thus the GUI.

-Michael

In fact the help for any LCL and RTL function should say how it can be used regarding threads.

Currently it's sufficient to know that the LCL is not threadsafe.

It is known that any function that accesses the GUI can only be called by the main thread.

That's one of the reasons, and since virtual methods and event handlers can be used almost everywhere, almost no method or property can ever be documented as being threadsafe.

DoDi

You cannot have multiple instances of an widgetset, and not multiple (different) widgetsets in one application.

What should be feasable are windows (forms) in more than only the main thread, when every thread uses its own message queue. Then a worker thread could e.g. update its progress indicator, in his own form, without blocking (or being blocked by) the main thread.

DoDi