Re: [ECOS] Time slice is not happening quiet alright

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Jon" == J Sevy <jsevy@mcs.drexel.edu> writes:

    Jon> Nick Garnett wrote:
    >> No, you have misunderstood. The eCos C library is thread safe,
    >> so whenever an IO operation takes place, such as printf(), a
    >> lock associated with the stream is taken. Any other thread that
    >> tries to do IO on the same stream will be blocked until the
    >> first thread releases it. This is standard mutual exclusion.
    >> Any thread that is not doing IO on that stream is not affected
    >> in any way.

    Jon> Actually, the eCos docs and configtool indicate that thread
    Jon> safety of standard I/O calls is configurable through the
    Jon> define CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS - though it
    Jon> seems to be enabled by default in the configtool, and I can't
    Jon> think of a context in which you wouldn't want this unless you
    Jon> aren't using the kernel...

With the normal approach to multi-threaded programming, i.e. any
thread can do just about anything at any time,you would always
thread-safe streams enabled. However there are other models of
multi-threaded programming, albeit not frequently used ones these
days. 

For example, the application could involve coroutines or cooperative
multithreading. There are no priority levels, no preemption, no
timeslicing. When a thread has control it will run until it explicitly
yields the cpu, and it will only do so at certain safe points in the
code. The middle of a printf() call would not constitute a safe point,
so it is guaranteed that only thread at a time can call printf() and
hence there is no need for a mutex lock. Of course blocking the whole
cpu while a printf() message is being transferred via a serial port
may not be the most sensible use of cpu cycles, but then a typical
deeply embedded application would not be calling printf() anyway
because there is nowhere for the output to go.

Another approach is master-slave threading, where a single master
thread is responsible for most I/O. The slave threads will be woken up
when appropriate to do some number crunching, and perhaps to perform
specialized I/O operations, but are not allowed to make arbitrary
library calls. Since only the master thread will call printf(), there
is no need for a mutex lock. A variant of this is where only thread in
the system will perform floating point operations, so there is never
any need to save or restore floating point state during a context
switch.

But for most applications, THREAD_SAFE_STREAMS should be enabled.
Hence it is enabled by default.

Bart

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