Thread-safeness of API functions

Joel Sherrill joel.sherrill at OARcorp.com
Fri Jul 30 15:41:34 UTC 2010


On 07/30/2010 10:34 AM, Joris van Rantwijk wrote:
> Hello,
>
> I have a few questions about thread-safeness of the RTEMS API.
>
> Are all functions in the C and POSIX API reentrant (except for the well
> known unsafe functions such as gmtime() and strtok()). For example, is
> it safe when two tasks concurrently call fprintf() for two different
> file descriptors?
>    
newlib is also used on Cygwin.  So any statements about
newlib apply there as well given assumptions about the
implementation about the per-target locking support
and REENT structure support.

For most of the reentrancy support, newlib uses a REENT
structure which is context switched by RTEMS on a per-thread
basis.  This covers most methods but not some FILE * AFAIK.

At this point, there is a PR to add this support and
it has patches.  If you are interested in this, it would be
a help to review and help shepherd the patches through
the newlib and RTEMS projects.

With that said, concurrent access of different file descriptors
should be OK.
> Is it also safe if two tasks concurrently call printf() for the *same*
> file descriptor?
>
>    
That may get you into trouble.
> POSIX.1c seems to guarantee that this is safe ("man 3p flockfile").
> In the source code of newlib, I see that indeed vfprintf() internally
> calls flockfile(). However flockfile() itself is not implemented either
> in newlib or in RTEMS. So it seems that concurrent calls to printf() for
> the same file descriptor are dangerous and could potentially crash the
> application. Is that true?
>    
I would have to agree with that until the newlib per target
locking support in in place for RTEMS.  Once there, I would
assume it would work fine.
> I have the same questions about sockets. For example, is it safe to
> concurrently call connect() for different sockets?
> Is it safe to concurrently call sendmsg() for the same socket?
>
>    
Yes.  One task will access it and the others will block
waiting for access.
> Please help me out. I can not find this in the documentation.
>
>    
Picky stuff under the hood. :)
> Greetings,
>   Joris.
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>    


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985





More information about the users mailing list