>>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 <[EMAIL PROTECTED]> > 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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel