[ros-dev] Race Condition?

Hartmut Birr hartmut.birr at gmx.de
Thu Nov 4 20:50:31 CET 2004



> -----Original Message-----
> From: ros-dev-bounces at reactos.com 
> [mailto:ros-dev-bounces at reactos.com] On Behalf Of James Tabor
> Sent: Thursday, November 04, 2004 7:55 AM
> To: ReactOS Development List
> Subject: [ros-dev] Race Condition?
> 
> 
> Hi,
> I believe with the new cvs changes by Hartmut caused the 
> illusive lockups I'm
> having to pop up more often now. Two today and yesterday.
> 
> This print out looks good, but I've had debug messages 
> overlapping each other
> at the beginning of the building process.
> 
> Debug output before lockup, there seems to be a double print 
> out, before just one
> every KernelTime, and the KernelTime looks like it had stopped,
> 

Hi,    

I can not reproduce your problem. I'm using a nearly clean cvs tree from
yesterday. I've add some little modifications that I can compile ros with
gcc-3.4.1 and the latest w32api. I use also modified inf files for the
installation. My test system is a scsi only mp machine. I assume that you
spoke about the up system. I'm using cmd.exe as login shell. I can compile
ros on ros. I think that the changes to the hal and the irq handling are not
the problem. I've add some changes for the sequence how threads acquire the
PiThreadLock and the DispatcherDatabaseLock. Currently the locking sequence
is only a problem for mp systems, not for up systems. The problem on mp
systems is that the first thread have acquire one lock and the second thread
the other. After this, the threads try to acquire the other lock. This is
currently not a problem of the up system, because after a thread has acquire
one lock the system runs on DISPATCH_LEVEL and no thread switching is
possible, no other thread can acquire the second lock. Currently there exist
more problems of the locking sequence for mp machines. You have reported the
KernelTime problem. In one of Filip's changes was a little mistake, which
has called KeUpdateSystemTime with the wrong irql. The time was always
reported to the interrupt time. I've fixed this, but didn't add a comment.


- Hartmut




More information about the Ros-dev mailing list