Re: [ECOS] Mutex & Asserts during initialisation

[Bart Veer <bartv@ecoscentric.com>]

>>>>> "Nick" == Nick Garnett <nickg@ecoscentric.com> writes:

    <snip>

    >> I can see the other side of this. You want to write a driver
    >> that can work in a multi-threaded environment, so you include a
    >> mutex in it. But then you want to call it from startup code.
    >> Rather than write a second specialized non-multi-threaded
    >> driver, or include some sort of flag that tells it to skip the
    >> locking and unlocking, it's much cleaner to simply consider the
    >> attempt to lock a mutex before the threading system has been
    >> initialized a harmless null operation.

    Nick> And this is exactly what happens. The kernel installs the
    Nick> idle thread as the current thread as soon as it is
    Nick> initialized so that mutexes and semaphores will operate
    Nick> correctly before the scheduler starts.

    Nick> However, device drivers are usually initialized before this
    Nick> point, on the assumption that the hardware should be
    Nick> initialized as early as possible. Wallclock devices are
    Nick> initialized a little later, but still before the idle
    Nick> thread.

    Nick> The driver initialization priority was set long before these
    Nick> layered I2C and SPI drivers were introduced. These are a
    Nick> fairly new feature, and there are clearly a few teething
    Nick> troubles.

    Nick> I suspect that the correct fix for this problem is to move
    Nick> the initialization of the DS1307 to after the idle thread in
    Nick> initialized. The simplest way of doing this is to make all
    Nick> wallclock devices use CYG_INIT_IO priority.

I agree this is the right short-term solution.

In the medium or long term we may want to rethink the predefined
constructor priorities. The current order is not necessarily optimal,
and I would like to see a few more categories. It is a hard problem
with lots of potential for circular dependencies and destabilizing
existing systems, so I need to think about it for a while before
coming up with a proposal.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss