TThread Question?

TThread Question?

Post by Jeff Dougl » Fri, 04 Jul 2003 08:23:43


Can a TThread class have member variables and functions that other classes
can call just like standard classes? I have a thread used by my app to log
events to a data base in the background. At times the app need to change a
varaible that the thread uses in the logging procedure. Can I implement it
as a simple public member var in the thread class?

Thanks

Jeff
 
 
 

TThread Question?

Post by Giulian » Fri, 04 Jul 2003 09:01:07


IMHO, it depends on the use that the thread makes of that variable.

If you need to synchronize the access to that variable, it's better that the
variable is a private member, hence you create either a public getter or a
public setter (member functions) which they implements a synchronization
mechanism across a critical section object. The successive step could be to
bind those members to a public property, in order to make the "synchronized"
property almost similar to a common public member var.

If you don't need any synchronization (I have some doubts, but it could be
so), you can make it a normal public member. For example, if the main
application only writes the variable while the thread only reads the variable,
and you can change the value at any time without the thread incurs in glitches
or races.

Giuliano

 
 
 

TThread Question?

Post by Edward Die » Fri, 04 Jul 2003 09:12:39


You can also make it a __property to give yourself more control over it than
a public data member.
 
 
 

TThread Question?

Post by Chris Uzda » Fri, 04 Jul 2003 13:23:20

"Jeff Douglass" <.> writes:


Yes. A TThread-derived object is still just a normal object. There
is NOTHING special about it. It mearly is a convenient way to spawn a
thread, and the thread starts by calling a function that calls a
member function (Execute) of your object.

Nothing restricts the thread to just being in that object, and nothing
prevents other threads from using that "thread" object.



Yes, but you should use a lock (TCriticalSection) to ensure that the
updates and accesses are atomic. Lock before each time you read or
write to that variable. Unlock immediately afterword.

--
Chris(TeamB);
 
 
 

TThread Question?

Post by gcardinal » Fri, 04 Jul 2003 19:32:25

On Wed, 2 Jul 2003 20:12:39 -0400, "Edward Diener" < XXXX@XXXXX.COM >





<<... object. The successive step could be to bind those members to a
public property, in order to make the "synchronized" property almost...>>

Giuliano