[fpc-devel] THREAD Programming IN FPC
Jason P Sage
jasonpsage at jegas.org
Tue Jan 9 16:12:21 CET 2007
>>Message: 3 - Jason P Sage Wrote (Original Message Snippet)
>> I was wondering the rule on MULTI-THREADING when
>> trying to make something THREAD SAFE.
>> I Have multiple threads running, and I MADE
>> EACH have its OWN set of
>> VARIABLES - so there isn't VARIABLE Stomping
>> from other THREADS.
>> The routines I CALL USUALLY have a few variables
>> they use to keep track of counters or stuff that
>> is only VALID during the life of the Call.
>> My Problem is sometimes THESE Variables that
>> are local to the sub routines are getting
>> stomped in longer routines (That perhaps
>> are getting task switched).
>Message: 4 From: Micha Nelissen <micha at neli.hopto.org>
> First, why the random capitalization ?
I capitalize based on words I'm trying to stress like I would in speech.
>Do you have a test program that reproduces this issue ?
No - I figured out the problem but appreciate your response nonetheless.
>It gets allocated on the stack, and every thread has its own stack.
This is what I thought - but a hard to locate bug made me start second
guessing myself after a few hours. As usual - the tough bugs are usually a
simple thing I overlooked.
>> Are AnsiStrings managed intelligently in threaded applications? Meaning -
>> they have the same rules as other variables concerning multi-threaded
>> applications or does the memory counters or "reference counts" to chunk
>> mem get hosed?
>They are not thread-safe AFAIK. It's hard to pass them safely between
>threads, though not impossible, however you have to know exactly how
I don't know what AFAIK means but I do understand what you mean here. To
pass an Ansistring from onw thread to another - as far I can tell - is
Make it so that the thread doing the move is the ONLY bit of code accessing
it at that point in time - and that it would need to be a synchronized thing
where the thread doing the copy or move ...
(e.g. (MyThread code) Self.MyAnsi:=MyThread.MyAnsi)
... MUST know for a fact that the data is there, and that no other tasks can
or will mess with that variable during the copy/move. This takes
synchronization between the two threads and possibly the main app as well
depending on implementation.
To Summarize: I was on the track with understanding how the threads were
working. They work like separate tasks in an operating system -
in fact - they are - but they share a common read/write memory and code
memory you could say simply.
And I sent my FPC mailing list message when I was baffled for a few hours on
something that just seemed fine when I looked at it. For this I apologize
but I was convinced for a time that a variable (a dynamic array of
ansistring) were getting stomped randomly - so I figured a thread problem
maybe. Eventually I got it down to a specific SPOT that was to mechanical to
be haphazard thread issue and then I located the bug.
Thank You for your help. I do try to refrain from sending messages everytime
I have an issue and I think I'm at about 5000 lines or more of code per one
mailing list question - and I do stay tuned for those times when I can
answer someone's question as well.
Hope all had a good holiday season and I hope all have a prosperous 2007.
Thank You Micha
Jason P Sage
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.7/620 - Release Date: 1/8/2007
More information about the fpc-devel