Re: [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