Hi - I read enough of this topic to compel me to respond. I have been working with Multi-threading in Free Pascal for a only a month or so now and I learned a great deal - and I have resigned to accepting there are design considerations I have had to adopt to get the results I wanted - that some times seem a bit less than ideal - but the pay offs have been wonderful. Let me digress a little...
First of all - THREADS running in a SERIAL fashion... Yup... I had that problem and I resorted to the "SAMPLE" tthreads.pp I think its called, as a starting point. It is an extremely simple example of multi-threading working that comes with either FPC or the FPC source download. I was fighting the serial execution - and then I ran that little tiny test program - and it worked. I tried to fix my code some more - same problem - but the little test program worked... so I finally (this is what I mean when I say I resigned to design changes) adopted that EXACT example as the foundation for how I would implement my THREADS. I create my threads like a thread pool, I create them all suspended. (Because that parts works pretty easy)... I set up the EXECUTE MY THREAD... as a loop... BUT - Each iteration calls its own SUSPEND method.... So it does a cycle and all I have to do is re initialize the "parameters" it works with BEFORE I resume it.... So its... as I call it "ready to fire" again, and then I just resume from the main program that is handling all these threads. Basically the test program has a working example of two threads looping at the same time and the simple output shows they are truly multi-tasking... I built my app into this same idea - with the addition that I suspend the loop each go round.... the suspended threads in turn become my "ready to do something" ones. If they aren't idle - they are either busy or trying to find the meaning of life. One of the biggest "issues" which is hard to debug if you aren't looking for it ... is WHY does a thread stay working when it should have finished the loop? It COULD be a bug in some dumb routine - but in many of my own cases - - it is accessing data that I wanted "SHARED" by all the threads... I know there is this critical section stuff and all that... but I found it simpler to make a RECORD STRUCTURE INSIDE the Threaded class that has all the DATA relevant to that INSTANCE - and then write "shared routines" that PASS this structure by value - so there is less need to worry about sharing data across the threads. I follow two rules - if it MUST be shared - treat it read only. If it can be copied to the thread's instance and does NOT really need to actively traded between the threads, I put it in this record structure - I refer to as "Thread CONTEXT". Now - to handle the ABSOLUTELY MUST allow main app to talk with thread etc. I keep it simple... each thread has a "structure" in the main program's space allocated - and the main program can read an write to it, and the thread can also... I try to keep the data simple - and less consequential to synchronization isn't a big deal - like an IDLE FLAG - or sending a message to the main program. I may write something out there, to a round robin like queue, and manage the pointers, and set up a way for the main program to read the info - when it can in a manner that doesn't interfere with the thread and vice versa. The moral of this story is four fold in my experience so far. 1: ITS Definitely worth it - the speed attained from multi threading, and in many cases the simplicity of having "specific" tasks go away and work and return when finished - well... I enjoy it. 2: Debugging a shared memory thing or one thread stomping another somehow - is a REAL pain to debug... have a great error logging system you can include or exclude with a compiler switch - they are priceless - never too big a log file when debugging -- speaking for myself. My favorite thing is a NEST COUNTER.. and my logs indent the nest level as periods "." so I can see when routines are entered and exited. (I don't use the integrated environment cause I can never get it configured right... I'm a command line junkie) 3: Keep it simple Silly Principle. Advanced methods not working? Resort to something you KNOW works (like the little demo) and build from there. It's often better to go around a mountain than climb the thing. Even though I'm always up for challenges - sometimes ya just need to (Maybe you've heard the famous comedian "Larry the Cable Guy" say this now famous slang term: "Git-R-Dun" (Get it Done ;) 4: Threading IS NOT always the best solution. This has been mentioned in a Lazarus WIKI I read. I'm building multi-user web applications and database stuff etc. So its great for me. If I was making a FTP server like FileZilla - I would do it also - even for the client - separate threads downloading different files at once... But frankly - as many know - sometimes alternatives can actually be faster - like multiplexing - or well managed messaging systems - where program gathers work to do in a loop, then processes each little task in order (or priority) one at time - ... depends on the application however. Have a great day all I have a ton of actual programming to do today - I love my work - I love Free Pascal Too... I'm such a fan. Jason P Sage _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
