Author: Robert Hyatt
Date: 08:01:06 09/11/03
Go up one level in this thread
On September 11, 2003 at 02:30:49, Tony Werten wrote: >On September 10, 2003 at 15:31:59, Robert Hyatt wrote: > >>On September 10, 2003 at 02:55:53, Tony Werten wrote: >> >>>On September 09, 2003 at 14:23:46, Andreas Herrmann wrote: >>> >>>>On September 09, 2003 at 04:10:53, Tony Werten wrote: >>>> >>>>>On September 09, 2003 at 03:21:34, Andreas Herrmann wrote: >>>>> >>>>>>On September 09, 2003 at 02:14:08, Tony Werten wrote: >>>>>> >>>>>>Hi Tony, >>>>>> >>>>>>i have just read inside a Delphi internals book last week a 50 side long capitel >>>>>>about Thread programming. It says that all local vars are save, but pay >>>>>>attention for global vars. See the help to the win api function >>>>>>EnterCriticalSection or the VCL object TCriticalSection as a good starting point >>>>>>to this theme. >>>>>> >>>>>>Andreas >>>>> >>>>>Thanks ( to all) >>>>> >>>>>It seems that "write" is not threadsafe when used for writing to the console. I >>>>>added some checks to make sure only 1 thread is writing at a time. Hope this >>>>>solves the problems. >>>>> >>>>>The problems became worse when I changed from writeln to write which seems >>>>>logic: more time spend in writing so bigger change for collisions. >>>>> >>>>> >>>>>Tony >>>> >>>>yes that can be a problem. I don't have this problem, because only my main >>>>thread (= the chess engine) writes to the standard output and my second thread >>>>polls the standard input and writes it to a own global buffer. >>>> >>>>Your problem could also be solved with Mutex (like Robert describes). See >>>>CreateMutex or OpenMutex for further help. >>> >>>I took the cheapo way. >>> >>>I made a global wb_busy boolean (set to false) >>> >>>In the writefunction I first do "while wb_busy do sleep(20)" >>> >>>then wb_busy:=true >>> >>>and end the function with wb_busy:=false >>> >>>It seems to work. >>> >>>Everybody thanks, specially the person who wrote me a week ago that consoles >>>aren't threadsafe. Now I understand what he meant :( >>> >>>Tony >>> >> >>That isn't safe./ >> >>What happens if _two_ threads simultaneously test wb_busy and find it zero? >> >>Both drop in, do their writes, and screw things up. >> >>Atomic locks prevent that by only allowing one program into the critical >>section at a time, guaranteed. > >Hmm, small chance that happens, but I might as well do it that way. Not much >difference (to program that is) > >Tony If you run long enough, or use enough processors, that "small chance" will show up with near 100% probability, right when it is the most embarassing. :) > >> >> >>>> >>>>Andreas >>>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>maybe a silly question, but one get quite desperate during debugging. Suppose I >>>>>>>have the followin code: >>>>>>> >>>>>>>procedure whatever(param:integer) >>>>>>>begin >>>>>>> do_something_heavy_with_param; >>>>>>>end; >>>>>>> >>>>>>>Say, the heavy stuff takes about 10 seconds. >>>>>>> >>>>>>>If during these secs another thread is calling this function, what happens ? >>>>>>> >>>>>>>Does every thread gets a "local copy" of the function ? >>>>>>> >>>>>>>On a single processor, there is a context switch, stuff is pushed on a stack, >>>>>>>and everything is safe. >>>>>>> >>>>>>>What about a dual ? I get the feeling that param is actually changed by the >>>>>>>second call. >>>>>>> >>>>>>>Tony
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.