This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Thread-safety protection of library functions

I have a project using an ARM9 and RL-ARM.

I'm wanting to use the malloc series of functions and have read the page "Thread-safety in the ARM C libraries" at:

http://www.keil.com/support/man/docs/armlib/armlib_chdfgjej.htm

Here it says that "some functions, such as malloc(), can be made thread-safe by implementing the _mutex_* functions".

So I looked at implementing the _mutex_* functions. There are details on:

http://www.keil.com/support/man/docs/armlib/armlib_chdfjddj.htm

But then I notice that my project, which already uses the fopen series of functions at startup (and currently only startup, when a single task is running), has these functions implemented in the file RTX_Lib.C (which is included by RTX_Config.C). Within the linker map file, I notice that _mutex_initialize is included but _mutex_acquire, _mutex_release and _mutex_free are not - Even when I include a test call to malloc in my project.

So the question is, would I be expected to do anything else to ensure that my calls to malloc() and the like are thread-safe?

Parents
  • I have a same problem. It looks somehow stange. Mutex is allocated and not used.

    From MAP file:

    _mutex_acquire                            - Undefined Weak Reference
    _mutex_release                            - Undefined Weak Reference
    heap2mt.o(i.___Heap_Initialize$realtime$concurrent) refers to mutex_dummy.o(.text) for _mutex_initialize
    

Reply
  • I have a same problem. It looks somehow stange. Mutex is allocated and not used.

    From MAP file:

    _mutex_acquire                            - Undefined Weak Reference
    _mutex_release                            - Undefined Weak Reference
    heap2mt.o(i.___Heap_Initialize$realtime$concurrent) refers to mutex_dummy.o(.text) for _mutex_initialize
    

Children
  • The solution is posted here:
    http://www.keil.com/forum/16315/#msg97767

    So to solve the problem, don't use "One ELF section per function" or better, use the
    __attribute__((used)) on that 2 functions.

    __attribute__((used)) void _mutex_release (void* mutex)
    { }

    __attribute__((used)) void _mutex_acquire(void* mutex)
    { }

  • It's a while since I did this now and I had to go back to the code to remind myself what I'd done. Since the thread has been re-lit, I thought it might be useful to post a follow up.

    In the file RTX_Config.C I added three lines:

    int _mutex_initialize (OS_ID *mutex) __attribute__((used));  // <<< Added
    
    void _mutex_acquire (OS_ID *mutex)   __attribute__((used));  // <<< Added
    
    void _mutex_release (OS_ID *mutex)   __attribute__((used));  // <<< Added
    
    #include <RTX_lib.c>
    

    My reasoning was much as was subsequently shown in the thread:

    http://www.keil.com/forum/16315/#msg97767

    However, that thread seems to assume that the functions are going to be implemented by the user. RL-ARM already implements the functions, so all that is really required is to ensure that they are pulled in by the linking process.