I'll try not to be a cheer leader ...
1. Reading and writing to memory is *DEFINITELY* not thread safe, however
..
a. Reading from a memory location that is never written to after it has
been initialised is thread safe (just remember to bracket the initialisation
code with a critical section).
b. If you want to share memory, consider using thread safe classes such as
TThreadList.
2. The whole VCL (not just screen controls) is not thread safe. You think
that you have gotten away with threaded access to some parts, but bugs will
eventually show up, and they will be very hard to debug, and if you get an
AV, the stack trace will most probably not show you where the bug is.
Example problem: We have a piece of code that generates metafiles to disk.
It needs a window handle, and so it creates a hidden TForm object and uses
its handle. This is all done on a worker thread, ie., not the main thread.
The code works fine 99.999% of the time, but occasionally, we get a list
index out of bounds error. After a lot of debugging, I finally managed to
track down the problem to TScreen. The list error happens when the form is
freed, and TScreen is in the middle of updating a list of forms, the for
loop runs past the end! In this sense, it is not only not thread safe, it
is thread deadly! Actually, the problem is the VCL is not re-entrant safe.
3. Classes such as TStringList, TStream, TList, TCollection are not thread
safe, but OK if you only use them from one thread. Beware of TStrings - it
is an abstract class and some of the subclasses may not be thread safe - eg.
if the subclass is the Lines of a TMemo or Items of a TListbox / TCombobox.
Dennis.
----- Original Message -----
From: "Matt Comb" <[EMAIL PROTECTED]>
Sent: Monday, June 20, 2005 11:17 PM
I would agree with everything you just wrote, but I'd be labelled a
cheerleader again ;)
Matt.
----- Original Message -----
From: "Kyley Harris" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, June 20, 2005 11:06 PM
Subject: [DUG] A Super Simple Summary of Thread Safe
A couple of simple things related to some of the conversations going on.
1/ Reading Memory is always threadsafe, unless the memory was freed. If
you don't use critical sections, you may read the wrong thing, because
something else overwrote the memory while you are reading it, in full or
part.
2/ Writing to Memory is not threadsafe, because you are altering the
memory structure, especially in more complex structures such as lists,
strings, objects etc. Writing to an integer could be considered
threadsafe, but it probably depends on the compiler, the computer, the
stack size, the natural integer size, etc etc.. The Purpose of a Critical
Section is much like a database transaction, to ensure that what you read
and write is correct at any given time, and to create a hands off
approach. if you do lots of reading, with few writes, and need speed, use
a TMultiReadWriteSyncronizer.
3/ Writing to the VCL GUI controls is only ever safe if the
CurrentThreadID = MainThreadID. It does not matter if you are reading or
writing. Why? Most of the controls like TEdit etc are TWinControls.
TWinControls have a Handle. if you use the handle, or create the handle
in any thread other than the main one windows will throw silent tantrums
and simply ruin the stability of your application. This is a design
issue. Don't expect to find it in the help files, or anywhere really :)
There are plenty more things that you need to do to make sure a GUI
accessing threaded processing doesn't go down the toilet but I hope this
helps.
regards
Kyley.
PS. This may not be 100% semantically accurate, but who has time for that
in these posts :D
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list
[email protected]
http://ns3.123.co.nz/mailman/listinfo/delphi
