Graeme Wrote:
>Thanks Jason - I don't recall you mentioning what platform you are working
>on, but I gather in is some *nix platform. The only thing you just proofed
>with your post is - threading is not working correctly!
>There shouldn't be a need for workarounds like suspending threads to get
>others to work. The whole point of threads, is let them run all at once in
>parallel. Delphi does it, Kylix does it, FPC under win32 does it! Linux
>doesn't! Instead of figuring out a workaround, rather submit a bug report
>with an example.
-- Jason Now --
Hi Graeme! I always enjoy your posts.
I seriously am not cycling the threads like your comment suggests. I
actually have proof that the threads are working EQUALLY well in Linux and
Win32... BUT this DOESN'T mean they are 100% - because like I was trying to
stress... I took that little demo with two simultaneous threads looping,
expanded on the "working" model. I can have any number of threads running
simultaneously no problem -
what I did was make it so - each of my threads "Execute" method - looks sort
of like:
procedure mythreadclass.execute
begin
repeat
CallSomeCodeHere;
self.bIdle:=true;
self.suspend;
until terminated;
end;
So I Create a pool of them, set the idle flags to false... why? Just so I
KNOW the thread finished the loop and is ready for another go around as I
call it.
(Geeesh... these self taught guys (like myself) don't even know the
nomemclature.. I don't know a semaphore from a mutex for example - but I've
dabbled with my own 32 bit OS's with task switching... fun but to much for
one person - go figure)
So, My Main program is actually a multiplexor - but its concentrating on a
little "Windowed" console app - like Free Vision - except mine is homemade
from the console, crt, mouse, keyboard units on up. (Mouse doesn't work in
my Linux.. but I digress.. prob a gpm thing )
Anyways - as its scanning for user IO at the "server", it has a millisecond
timer thing, that basically says every X milliseconds, see if there are any
new arrivals - (jobs to do) - and then it grabs info about all the new
arrivals until processed, in this order....
1: Look for those IDLE threads in the thread pool, Got One? Cool, (Its still
suspended)
2: load up the variables in the thread pertaining to the JOB - basically
initialize it with all the info it needs to perform a cycle....
3: "RESUME IT"... Good Bye thread - its off and running. I don't even THINK
about it again until its idle again... (well, the main program doesn't even
consider it - I should say - until its self.bIdle=TRUE) so I'm not doing
all this thread micro-management that your comment seemed to suggest, and
was a response to.
4.... meanwhile main program finishing "launching" work tasks, and when
done, goes back to UI stuff, and what ever. This all happens very smoothly
and I don't think I'll need to change this architecture until my web
applications are getting nailed like 50 requests a second or something -
where WORK TO DO makes the SERVER UI to unresponsive under load. Either way
- I just change the LOOP that tries to tackle all pending work at once - to
a controlled number, and grab more stuff each go round...
Behind the scenes - the threads are purring away - I have a couple "SLEEPS"
here and there - but only when it seems appropriate - like the "THREAD is
waiting on something..." ... on in the main program - ... but these are not
related to each other - just my program trying to give up the CPU when its,
(in one program I have a flag literally named) "bTrulyIdle". Truly Idle
menas - I looked around - there's nothing to do.... so it "Sleeps" (Actually
in my prog - if win 32 I call win32 API - and in linux I use sysutils sleep,
so I have a function called "Yield" that wraps this up rather nicely .. I
have reasons - I TRY to not use sysutils in ONE app due to EXE size reasons
- but in linux I just deal - cuz I need the SLEEP function - in all my other
apps SIZE is not a factor - straight up speed is - (Free Pascal seems GREAT
to me in this arena....)
Jason P Sage
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
