I'd created a Delphi Thread (TThread) and it runs fine. But now, I need to
pass some parameters to it. How can I do it ?
Thanks in advance,
Gabriel
There was a link here posted by someone (Peter?) some time ago with a
threading tutorial. Best doc ever from zero to successfull threading, even
though to expert level. You might find the lecture interesting if you want
to do threading. I just wish the guy would write one on interfaces :)
--
Andrei "Ndi" Dobrin
Brainbench MVP
www.Brainbench.com
Not Peter; Martin.
http://www.pergolesi.demon.co.uk/prog/threads/ToC.html
--
Rob
At creation time - easy, add extra parameters to the constructor.
To change fields in the thread after it has started running, you may well
require a critical section to prevent the thread from reading a
partially-changed field.
To communicate data to the thread in a more controlled way, you need a
windows message queue, or some other waitable threadsafe queue, to wait on
for your parameter objects/whatever . If you don't need timeouts, and
there's only one thread waiting on the queue, a Windows message queue is as
good as anything for shovelling objects at a thread.
Rgds,
Martin
I added parameters to the constructor and it's ok now.
I also loved that article about threads.
It was really helpfull thanks a lot.
>* Try a global variable
>* Try a thread-local variable you set after creating (suspended), setting,
>then resuming.
I'd recommend this option.
>* When building thread class, override the constructor to accept parameters.
Can be nice, but what with overloading & whatnot, it just feels a bit
messy.
> There was a link here posted by someone (Peter?) some time ago with a
>threading tutorial. Best doc ever from zero to successfull threading, even
>though to expert level.
Thanks - although there are a few corrections I need to make at some
point...
>You might find the lecture interesting if you want
>to do threading. I just wish the guy would write one on interfaces :)
Don't tempt me ;-)
MH.
Depends on the parameter. If accessing it takes more than one instruction,
it is possible to suspend it in the middle of an access.
> >* When building thread class, override the constructor to accept
parameters.
>
> Can be nice, but what with overloading & whatnot, it just feels a bit
> messy.
You have overloaded thread constructors?
Rgds,
Martin
>Depends on the parameter. If accessing it takes more than one instruction,
>it is possible to suspend it in the middle of an access.
Erm... the whole point of creating the thread suspended is that it
executes exactly 0 instructions before you resume it.... it's not like
the thread is started and then immediately suspended!
>You have overloaded thread constructors?
constructors for TThread have the same object pascal rules as anything
else - you just need to be aware that when you call the inherited
constructor, there'll be a CreateThread API call in there somewhere.
MH.
You're right. I misunderstood your reply. Also, the post before was
confusing - it had stars & things, like C, and this makes me start to post
rubbish.
Rgds,
Martin
> There was a link here posted by someone some time ago with
> a threading tutorial. Best doc ever from zero to successfull
> threading, even though to expert level. You might find the lecture
> interesting if you want to do threading.
Try this one
http://www.pergolesi.demon.co.uk/prog/threads/ToC.html
> I just wish the guy would write one on interfaces :)
What's your problem with interfaces? What exactly do you want to know?
JensG
Thanks, Rob. And Martin. I've been looking for that.
Errata: I mean from zero to nice but *not* expert. I was trying to not
scare the reader into thinking it's a 400-page manual to bit masking :)
Did that by forgetting "not".
> What's your problem with interfaces? What exactly do you want to know?
Ermm. Well, the help isn't very helpful (never has been unless you can
already code to a certain level). I already use (close-to-master) DLL and
linking to and from them, as I already have implemented and field-tested
addon systems containing from window colors to threaded helpers.
As people told me, interfaces are basically similar DLL exports, but
language independent. As in one exports the function along with needed
structure definitions so you don't have a header (translation). Good I say,
C function decorating was not such a hot idea. Lovely so, until I tried to
implement them. Pains arise:
* Pain nr 1: Attempted to implement an export system so one can write
addons with interfaces. Some people that wanted addons code C or VB and I
thought I'd help. Creating an export class also loaded a weird executable
with my main program. Closing it would kill the app. Interface was slow. And
worse of all, one can't export (could not find how) more than basic data, so
bye-bye record. Each string, byte, DWord, etc needed a GET and a SET and
some validation code. WAY TOO MUCH to implement over a 1 million code
project. I was told that's not the way. Sherlock here was not able to
explain how it works. Didn't find a tutorial, end of that episode.
* Pain nr 2: Attempted to import an AX control. Delphi built me a TLB that
interfaced all. Lovely. Except that the imported TLB didn't work as
designed. I don't know if the designer was a moron or Delphi has a bug, but
simple things as assigning an event crashes it. I can get/set properties,
emulate events, but not intercept any. And since this is a USB remote
control app, you can imagine how useful it is without event handling. No
help, no knowledge, dropped. (Not-so-end-of -episode, I'd still like to
throw the buggy nVIDIA remote control panel and bind the buttons as I like.
It uses the X10 AX control). Oh and it crashes when I press the remote, so
events sorta work... . nVIDIA developer stie provides no help to this, as
it's built by X10. And X10 only does industrial solutions, so
you-need-not-know-this. Darn.
* Pain nr 3: Never could actually understand what CoCreateWhatever does.
Never could understand the mechanism since I never got a real, human
explanation. Here I am, with full docs (OS and Delphi), working examples and
the only way I can implement an IContextMenu is to modify the demo. Does
anyone have a doc that explains that? Can't be hard, but per-function help
doesn't help me get an overview...
Isolated problems can be googled, helped, demoed, but an overview, an
actual "feel" of this needs some sort of a tutorial. Every time I needed to
do an interface I ran away from it because this lack of documentation. And
you can't asking around 1-200 questions on a group, either. That's around
how many questions a good tutorial answers by just keeping your thoughts
down the right lane.
Oh and the above mixing IObject with TLB and CoCreateInstance should give
you an idea of how much broken my compass is. Outright annoying, considering
I can build a demo of just about any other concept or API call all by
myself.
Sorry about the long post, just getting all the frustration out :)
Ndi
>> > Best doc ever from zero to successfull
>> > threading, even though to expert level.
>
> Errata: I mean from zero to nice but *not* expert. I was trying to not
>scare the reader into thinking it's a 400-page manual to bit masking :)
> Did that by forgetting "not".
>
*Stare* ;-)
Actually, with the stuff I know, I could definitely take it up to an
expert level including lots of unusual and arcane things. After all, I
wrote the tutorial four years ago.
Tings I'd like to update:
- Critical sections - how and why they works.
- Using interlocked ops in user mode apps (Didn't really explain it
well)
- Writing your own snc primitives: a debug library that checks for
errors.
- More advanced error and status checking: dependencies, keeping track
of context switches and runtime tolerancing.
- "Can't live with or without" - Why some things are impossible
without AtomicSignalAndWait.
- The User Mode / Kernel Mode interface: programming for efficiency.
- APC's, I/O completion: on the quest for even more efficiency.
And just for fun (and just to mess with ppls heads and give myself a
boundless sense of superiority :-) ) even though it's not Delphi, I'd
also like to include and good background material:
Windows Synchronisation Internals:
- IRQL, what's that?
- Blocking and paging rules for different IRQLS.
- Kernel dispatcher objects.
- They're semaphores and mutexes, but not as we know them!
- Holding on to the dispatcher lock.
- Basic Spinlocks & flags.
- More spinlocks - In stack , out of stack, queued.
- Using spinlocks at dispatch and DIRQ level
- Scheduling DPC's.
- Synchronisation across paged / nonpaged datastructures
- Synchronisation in the I/O manager.
- Synchronisation in the memory manager.
- And you thought APC's only came in one flavour?
- Misc tidyup.
Unfortunately, I reckon that by the time I include all that, it'll be
up to 22 chapters, and I *so* need to finish my current project first
:-(
MH.