[Prev][Next][Index][Thread]
Re: a possible bug in osenv_timer_init ?
> a classical one, I guess:
> (excerpt from "oskit/dev/x86/timer.c")
>
> static int initialized =3D 0; /* guard against multiple invocations */
> ...
> A:
> if (initialized)
> return;
> B:
> initialized =3D 1;
> ...
>
> suppose two invocations occur (I guess this can occur, if drivers are =
> implemented as separate processes and two request independantly of each =
> other a timer initialization, however this can easily be removed, if the =
> OS calls it when initializing itself, before loading any other =
> drivers...). one gets to label B before switched, other one gets =
> execution control and again executes up to B, since the variable will be =
> still 0... Solution: a lock? I know there is no lock in the osenv_ =
> API... but I will try to implement it, once I get to know the code =
> better :).
> FtpDaemon
The driver code is non-reentrant. If you have multiple threads/processes,
then you must provided the locking externally to the osenv code.
In other words, if you hit that race condition, you will likely hit
dozens of others, but it is your own fault for not implementing the
osenv API correctly.
Note that if the drivers are in separate address spaces, then you
will need to provide the timer_pit routines, but the rest of the
timer code will be per-process and will not be a problem.
Race conditions like these are why some operations are defined to allow
blocking, while others are not. You should tie into osenv_{sleep,wakeup}
to allow multiple threads execute in the driver set.
Please read the documentation, especially the sections on osenv.
Kevin T. Van Maren
University of Utah, CSL