Query concerning use of flockfile/funlockfile in stdio FILE related functions
Tue Sep 7 20:20:00 GMT 2004
Antony KING wrote:
> I have a query concerning the use of the flockfile/funlockfile functions
> in the stdio sub-component of newlib. It relates to a requirement we
> have of being able to call the sprintf/sscanf class of functions from
> interrupt handlers in our RTOS.
> One of the restrictions of interrupt handlers in our RTOS is that they
> cannot block on synchronisation objects which is unfortunate since the
> sprintf/sscanf class of objects implicitly use the locking API defined
> in sys/lock.h via flockfile/funlockfile (I have implemented the locking
> API using the synchronisation objects available in our RTOS).
Anthony, in the sprintf/sscanf case, as you have noted, the lock object is only
known to the sprintf or sscanf functions (they are part of local FILE objects).
Thus, there should never be a blocking situation which technically meets the
"letter of the law" stated above. Is the restriction more strict than you have
I have noticed that the local FILE lock objects are not being initialized which
is an error :(.
> This restriction is not a problem when using FILE objects created via
> fopen et al since they normally refer to resources which require the
> proper thread protection afforded by the locking API. However for the
> sprintf/sscanf class of functions using the locking API is unnecessary
> since the FILE objects created by these functions for use by the "real"
> functions _vfprintf_r/__svfscanf_r should be inherently thread safe (as
> they are allocated off the stack).
> It should therefore be possible to dynamically detect this scenario and
> not use the locking API and hence allow me to use the sprintf/sscanf
> functions from my interrupt handlers.
> Ideally I would like to add a flag to the _flags field of the FILE
> structure to indicate whether a lock object is present or not but
> unfortunately there are no free bits left. Another possibility would
> have been to use the fact that the sprintf/sscanf fucntions set the
> _file field of the FILE structure to -1 but thus is not reliable since
> it can take the value of -1 in other instances.
> One thought is to extend the locking API to to include "not initialised"
> initialiser APIs whose purpose is to allow the locking API acquire and
> release methods detect this state and ignore the lock/unlock requests.
> Its not very nice but would work without changing the layout of the FILE
> structure (by increasing the size of the _flags field from 16 bits to 32
> bits). Also I am uncertain how this change to the locking API would
> impact other implementations (e.g. linux/cygwin).
The locking API should not be changed. It is easy enough to check for the
__SSTR flag to avoid locking. This flag is set for all the string printf
operations but isn't currently used for the sscanf set.
-- Jeff J.
More information about the Newlib