during the execution the threadvar that they touch is the one used by the main thread not the newly created thread's data. Use the execute method anything else is not guarantied to execute in the thread context, well actually unless you call it directly from the thread's execute method it is guarantied to not execute in the thread context but you get the point.
So you are referring to just time efficiency like i said?
sorry for me time efficiency is something different that has nothing to do with initialization. If you mean synchronization ee the right command at the correct time then yes that is what it is required.
There is no other harm done in doing that in main thread.
Harm? if proper care is taken it does not matter from where is done.
Actually i can see opposite cases where initializing thread variables in main thread is the only working way.
thread variables and threadvars are two different things one exist before the thread execution begins the other it does not, one can be accessed from outside the thread context the other can not, in any case it is wise to not mix thread data with application data at all if possible.
Say you want to split the load of going through some data that changes at realtime. The way i see it, you would have to give the partial data snapshot to each thread which they will then begin working on. If you read the snapshot in Execute you would get overlaps and different threads would get access to same data at random places.
No you can't, if proper locking is used then it should not be possible for the threads to overlap, on the contrary, by introducing a thread safe list, that any number of threads can query for data, you have a more dynamic design, both on number of threads and size of data acquired from the thread in each iteration. Pushing data is not a recommended strategy in multi threading.
There are thread variables that you put in the public section of inherited TThread class in type section.
No there are none, public variables in any class are an indicator of bad design, either the designer or the programmer needs to be fired, as always there are exceptions, I have never seen one but that is probably my narrow view. ALL thread variables must be protected against outside access. No public variables no protected variables no direct access to internal variables from outside the thread context with out a proper locking and no access to workload variables from outside the thread code. Only variables that are used to initialize the process or return information/data to the application are allowed to be accessed from outside and those are not to be used directly in the thread execution process.
Or some that are passed in through a constructor.
Yes this can be seen as the parameters in a procedure, I prefer a public method that will initialize those variables, instead of constructor parameters, it is more "usable" but both are acceptable solutions to the problem.
Recent
