Re: [ECOS] thread safety in sprintf ...

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Tom" == Thomas BINDER <Thomas dot Binder at frequentis dot com> writes:

    Tom> When CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS is turned off,
    Tom> will (the libc) sprintf function crash the system if it gets
    Tom> called from several threads???

    Tom> Or are there just problems if several threads write to the
    Tom> *same* string?

    Tom> Will fprintf still work properly without
    Tom> CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS ??

sprintf() should not be affected by THREAD_SAFE_STREAMS. The shared
data structures provided by this configuration option are the FILE
structures, and especially the various buffers and indices associated
with those structures. sprintf(), vsnprintf(), etc. all create a
private FILE structure on the stack so that is always per-thread and
no locking is required.

If several threads write to the same string then the system's
behaviour is inherently undefined, and THREAD_SAFE_STREAMS will not
change that.

If there are several threads calling e.g. fprintf() on the same stream
(i.e. using the same FILE object) with no synchronization then you
must have THREAD_SAFE_STREAMS enabled, thus making the system do the
required synchronization for you. There are other scenarios. For
example an application may be written such that all fprintf() calls
happen in a single thread, and hence there are no synchronization
issues. Alternatively there may be e.g. a mutex at the application
level which prevents multiple threads calling fprintf() on the same
stream at the same time. In such scenarios THREAD_SAFE_STREAMS is not
required, which is why it is a configuration option.

Bart

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

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