Nice message! I've found the same things when threading and trying to keep a log. Currently I'm using the critical section bit. Also I found in freePascal that when dealing with opening files etc in different modes, that the file mode value seems to be global - so - I made a serialized mechanism for file handling for writing.. not for reading.. just writing... so when I open a file - I STOP EVERYTHING, set the file mode, open, then set the file mode back, then SET EVERTHING to GO again. It really doesn't cause me much problems as I keep things open if necessary, and frankly, I'm doing a ton of opens to write data in my application... so I have the mechanism there so those bizarre bugs that can happen with threads don't occur. (If I'm wrong about this... it wouldn't be hard to change... but testing showed that when I start trying to read/write .. especially with block read/write - I run into problems - but not any more)
I also 100% agree that not every application needs to be multi-threaded. I believe there is an art to making good multiplexors... and when done properly they can be EXTREMELY fast - and faster than typical threaded equivalents because you gain cpu cycles that might of been previously lost to task switching mechanisms at the CPU/OS level. Multiplexors are applications that "manage multiple tasks in one thread".... In fact - one could build a whole OS that way... but you lose the integrity - if one thing goes - it all goes lol. Well.. not trying to hijack the UDPBlockSocket thread - just good stuff I wanted to respond to :) Well - Happy Holidays to all! --Jason P Sage Nicolás Aragón Lobo wrote: > Hi Veli! > > On 14/12/2009 14:41, Veli BOZATLI wrote: > >> [...] >> if CanRead(100) then begin >> recv := RecvBuffer(@fUDPBuf, 1325); // I log the time after this line >> > Where do you log it to? > > I've been doing some speed tests recently and one thing I've found out > is that logs to file affect performance noticeably when using several > threads. Worse if protected using a critical section, but bad anyway... > I suspect that calls to plain WriteLn are internally protected, and > differently in different Windows versions. > > The (partial) solution has been to keep a log that's private to each > thread in a TStringList, later dumping to the general output, when > thread dies. Still in need of some synchronization, but far better than > using the critical section each time I want to leave some trace. > > It might be better to avoid Write completely and log to a socket. > > Depending on what the application does, it's also possible to avoid > threads completely. I don't mean using events style, but simply > processing data in the main thread loop as they come. I worked in a > program that presented stock market data on screen. It *had* to be > extremely fast. A solution that worked very well was to determine frames > per second of screen presentation, slice it in half and give one half to > receiving and processing, one half to painting. > > Hope it helps! > > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ synalist-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/synalist-public
