[fpc-devel] THREAD Programming IN FPC

[Jason P Sage]

>>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 -
do
>> they have the same rules as other variables concerning multi-threaded
>> applications or does the memory counters or "reference counts" to chunk
of
>> 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 
>things work.
>
>Micha

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[1] code)        Self.MyAnsi:=MyThread[2].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
4:12 PM