Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2010-01

FCL Thread-safety

11 messages · 5 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Nikolai Zhubr

Hello people,

Is FCL thread-safe?
To be more precise, what I mean is the following. I'm going to create 2 (or more) components so that they are completely unrelated to each other in _my_ code and use them separately within different threads (implemented as TThread descendants if it matters) with no syncronization/serialization whatsoever. Can I be sure that such components will not interfere each other implicitely (somewhere deep inside the FCL)?

And just in case someone knows, will zeoslib components be thread-safe in the same sense? From a brief look, zeoslib doesn't use global variables too much, so I suppose zeoslib thread-safety mostly depends on the FCL thread-safety. (Except that zeoslib's internal library loader seems definitely not thread-safe, but this is no problem because normally it should only be used once at the very beginning)

Thank you!

Nikolai

Reply by email

Burkhard Carstens
to Nikolai Zhubr
Nikolai Zhubr wrote 10 lines
Hello people, Is FCL thread-safe? To be more precise, what I mean is the following. I'm going to create 2 (or more) components so that they are completely unrelated to each other in _my_ code and use them separately within different threads (implemented as TThread descendants if it matters) with no syncronization/serialization whatsoever. Can I be sure that such components will not interfere each other implicitely (somewhere deep inside the FCL)?

No, you can't be sure. E.g. the fcl-xml stuff in latest released fpc-2.4.0 is *not* thread-safe, because it uses avl-tree which is not thread-safe. See http://mantis.freepascal.org/view.php?id=12984 and note: This bug is marked as "fixed in 2.4.0" which is (partly) wrong. The problem with xml stuff depending on avl-tree is fixed only in trunk and in fixes_2_4 (i.e. 2.4.1).
So using e.g. xmlcfg is thread-safe only, if fpc > 2.4.0 is used. About avl-tree: IIRC it *can* be used in a thread-safe manner, but by default, it is not thread-safe. So any component using avl-tree might not be thread-safe.
There might be much more stuff like this, so I recommend to verify every components you intend to use.

Show quoted text 8 lines
And just in case someone knows, will zeoslib components be thread-safe in the same sense? From a brief look, zeoslib doesn't use global variables too much, so I suppose zeoslib thread-safety mostly depends on the FCL thread-safety. (Except that zeoslib's internal library loader seems definitely not thread-safe, but this is no problem because normally it should only be used once at the very beginning)

No idea, never used zeos.

regards
Burkhard

Reply by email

Nikolai Zhubr
to Burkhard Carstens

27.01.2010 10:09, Burkhard Carstens:

Show quoted text 6 lines
So using e.g. xmlcfg is thread-safe only, if fpc> 2.4.0 is used. About avl-tree: IIRC it *can* be used in a thread-safe manner, but by default, it is not thread-safe. So any component using avl-tree might not be thread-safe. There might be much more stuff like this, so I recommend to verify every components you intend to use.

Luckily, I will not use any xml stuff yet.
However, verifying all of the components that my program might (also implicitely) link to is quite a hard task... And it is very possible to make a mistake, thinking that the code is thread-safe while in fact it is not. Obviuosly this will lead to a total nightmare then. I was hoping someone can give an idea about thread-safety in FCL (other than xml) in general.

Thank you!

Nikolai

Reply by email

Marco van de Voort
to Burkhard Carstens: No, you can't be sure. E.g. the fcl-xml stuff in latest released fpc-2.4.0 is *not*…

In our previous episode, Burkhard Carstens said:

Show quoted text 9 lines
> (implemented as TThread descendants if it matters) with no > syncronization/serialization whatsoever. Can I be sure that such > components will not interfere each other implicitely (somewhere deep > inside the FCL)? No, you can't be sure. E.g. the fcl-xml stuff in latest released fpc-2.4.0 is *not* thread-safe, because it uses avl-tree which is not thread-safe. See http://mantis.freepascal.org/view.php?id=12984 and note: This bug is marked as "fixed in 2.4.0" which is (partly) wrong.

Avltree is fixed in 2.4.0 (you can set an own manager), and that is what the report is about (see title: "Patch : thread safe/non-safe avl_tree implementation" )

XML is not fixed.

Reply by email

Burkhard Carstens
to Marco van de Voort
Marco van de Voort wrote 17 lines
In our previous episode, Burkhard Carstens said: > > (implemented as TThread descendants if it matters) with no > > syncronization/serialization whatsoever. Can I be sure that such > > components will not interfere each other implicitely (somewhere > > deep inside the FCL)? > > No, you can't be sure. E.g. the fcl-xml stuff in latest released > fpc-2.4.0 is *not* thread-safe, because it uses avl-tree which is > not thread-safe. See http://mantis.freepascal.org/view.php?id=12984 > and note: This bug is marked as "fixed in 2.4.0" which is (partly) > wrong. Avltree is fixed in 2.4.0 (you can set an own manager), and that is what the report is about (see title: "Patch : thread safe/non-safe avl_tree implementation" ) XML is not fixed.

Right, that's why I wrote "(partly) wrong" .. relation to xml was the main point in that bug report and your final note "Solved now DOM no longer depends on avltree." together with "fixed in 2.4.0" might give the impression, XML is fixed in 2.4.0 ..

regards
Burkhard

Reply by email

JoshyFun
to Nikolai Zhubr: 27.01.2010 10:09, Burkhard Carstens: Luckily, I will not use any xml stuff yet. However,…

Hello Nikolai,

Wednesday, January 27, 2010, 8:36:53 AM, you wrote:

NZ> Luckily, I will not use any xml stuff yet.
NZ> However, verifying all of the components that my program might (also NZ> implicitely) link to is quite a hard task... And it is very possible to NZ> make a mistake, thinking that the code is thread-safe while in fact it NZ> is not. Obviuosly this will lead to a total nightmare then. I was hoping NZ> someone can give an idea about thread-safety in FCL (other than xml) in NZ> general.

Which is the meaning of "Thread Safe" for you ? Same object in two threads or same object instance in two threads ?

For the second one, most objects are NOT thread safe, but for the first one most objects are thread safe as far as I know.

Best regards, JoshyFun

Reply by email

Leonardo M. Ramé
to Nikolai Zhubr: Is FCL thread-safe? To be more precise, what I mean is the following. I'm going to create…

I can confirm FCL-XML is thread safe, at least in FPC 2.5.1, also Zeos as far as you create a new connection to the database inside each thread.

I'm using both libraries in a multithreaded daemon that receives an XML file via socket, then connects to a Postgres database using Zeos.

While developing this, the first issue was many database deadlocks, and transaction problems caused because I was sharing a global database connection, the solution was creating an instance of the database connector in the Thread constructor, and destroy it in the Thread destructror. Regarding the FCL-XML, I was using an old version based on AVLTree, and found it have many problems when working within threads, all of them solved after upgrading to the latest version.

Leonardo M. Ramé
http://leonardorame.blogspot.com

Nikolai Zhubr wrote 31 lines
From: Nikolai Zhubr Subject: [fpc-devel] FCL Thread-safety To: Date: Tuesday, January 26, 2010, 11:08 PM Hello people, Is FCL thread-safe? To be more precise, what I mean is the following. I'm going to create 2 (or more) components so that they are completely unrelated to each other in _my_ code and use them separately within different threads (implemented as TThread descendants if it matters) with no syncronization/serialization whatsoever. Can I be sure that such components will not interfere each other implicitely (somewhere deep inside the FCL)? And just in case someone knows, will zeoslib components be thread-safe in the same sense? From a brief look, zeoslib doesn't use global variables too much, so I suppose zeoslib thread-safety mostly depends on the FCL thread-safety. (Except that zeoslib's internal library loader seems definitely not thread-safe, but this is no problem because normally it should only be used once at the very beginning) Thank you! Nikolai _______________________________________________ fpc-devel maillist  -  http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Nikolai Zhubr
to JoshyFun: NZ> Luckily, I will not use any xml stuff yet. NZ> However, verifying all of the…

27.01.2010 13:59, JoshyFun пишет:

Show quoted text 14 lines
Hello Nikolai, Wednesday, January 27, 2010, 8:36:53 AM, you wrote: NZ> Luckily, I will not use any xml stuff yet. NZ> However, verifying all of the components that my program might (also NZ> implicitely) link to is quite a hard task... And it is very possible to NZ> make a mistake, thinking that the code is thread-safe while in fact it NZ> is not. Obviuosly this will lead to a total nightmare then. I was hoping NZ> someone can give an idea about thread-safety in FCL (other than xml) in NZ> general. Which is the meaning of "Thread Safe" for you ? Same object in two threads or same object instance in two threads ?

The first one. (I described my scenario a bit more specifically in my initial post of this thread)

Nikolai

For the second one, most objects are NOT thread safe, but for the first one most objects are thread safe as far as I know.

Reply by email

Nikolai Zhubr
to Leonardo M. Ramé: I can confirm FCL-XML is thread safe, at least in FPC 2.5.1, also Zeos as far as you…

27.01.2010 15:30, Leonardo M. Ramé:

Show quoted text 7 lines
I can confirm FCL-XML is thread safe, at least in FPC 2.5.1, also Zeos as far as you create a new connection to the database inside each thread. I'm using both libraries in a multithreaded daemon that receives an XML file via socket, then connects to a Postgres database using Zeos.

Thank you very much! That is very similar to what I'll be doing, except that I just dont use XML. Yes, I'll create 1 connector per thread of course. The only concern then is how to ensure that thread-safety is not (ocasionally) destroyed with some future FCL and/or zeoslib versions. It somehow seems quite uneasy to design a simple and yet reliable regression-test for automated testing. On the other hand, verifying it all by hand is also not what I'd be dreaming of.

Thank you!

Nikolai

Show quoted text 12 lines
While developing this, the first issue was many database deadlocks, and transaction problems caused because I was sharing a global database connection, the solution was creating an instance of the database connector in the Thread constructor, and destroy it in the Thread destructror. Regarding the FCL-XML, I was using an old version based on AVLTree, and found it have many problems when working within threads, all of them solved after upgrading to the latest version. Leonardo M. Ramé http://leonardorame.blogspot.com

Reply by email

Leonardo M. Ramé
to Nikolai Zhubr

Well, I had to create a simple testing application that generates random XML messages and stress-test the daemon.

About Zeos, my app does not compiles against the svn version, but a copy of an approved (by me!) version. Every couple of months, I get the latest version, then compile and test, if this works ok, I copy the whole directory of Zeos and place it in my app's dir tree, this tree is a frozen version of Zeos. This way, I'm not concerned about changes in the libraries.

Leonardo M. Ramé
http://leonardorame.blogspot.com

Nikolai Zhubr wrote 56 lines
From: Nikolai Zhubr Subject: Re: [fpc-devel] FCL Thread-safety To: Date: Wednesday, January 27, 2010, 12:27 PM 27.01.2010 15:30, Leonardo M. Ramé: > I can confirm FCL-XML is thread safe, at least in FPC 2.5.1, also > Zeos as far as you create a new connection to the database inside > each thread. > > I'm using both libraries in a multithreaded daemon that receives an > XML file via socket, then connects to a Postgres database using > Zeos. Thank you very much! That is very similar to what I'll be doing, except that I just dont use XML. Yes, I'll create 1 connector per thread of course. The only concern then is how to ensure that thread-safety is not (ocasionally) destroyed with some future FCL and/or zeoslib versions. It somehow seems quite uneasy to design a simple and yet reliable regression-test for automated testing. On the other hand, verifying it all by hand is also not what I'd be dreaming of. Thank you! Nikolai > > While developing this, the first issue was many database deadlocks, > and transaction problems caused because I was sharing a global > database connection, the solution was creating an instance of the > database connector in the Thread constructor, and destroy it in the > Thread destructror. Regarding the FCL-XML, I was using an old version > based on AVLTree, and found it have many problems when working within > threads, all of them solved after upgrading to the latest version. > > > Leonardo M. Ramé http://leonardorame.blogspot.com > _______________________________________________ fpc-devel maillist  -  http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Nikolai Zhubr
to Leonardo M. Ramé

27.01.2010 17:49, Leonardo M. Ramé:

Show quoted text 9 lines
Well, I had to create a simple testing application that generates random XML messages and stress-test the daemon. About Zeos, my app does not compiles against the svn version, but a copy of an approved (by me!) version. Every couple of months, I get the latest version, then compile and test, if this works ok, I copy the whole directory of Zeos and place it in my app's dir tree, this tree is a frozen version of Zeos. This way, I'm not concerned about changes in the libraries.

Yeah, I see. I'll probably have to work out some similar approach.

Nikolai

Leonardo M. Ramé http://leonardorame.blogspot.com

Reply by email