[ros-dev] Race Condition?

[James Tabor]

Hi!
Hartmut Birr wrote:
> 
> 
> 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

oh okay, mp = SMP

> 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

Okay.

FYI, you have to let ros run for over ~12 hours to get it to fail. After dividing
the KernelTime clock that would be approx 11.85 hours until it froze. Oh, this
was tested w/o the explorer running just the straight cmd console after boot up.

I will start with the current cvs tree at this time and restart the run.

I'll post some more information next time. 8^(

Thanks,
James