But we need to consider syslog call from interrupt context too. So I think the 
simple modification is:
1.Drop the critical section
2.Keep the global variable
In FLAT/PROTECTED build, all user space applications have to share the same 
variable.

-----Original Message-----
From: Gregory Nutt <spudan...@gmail.com> 
Sent: Monday, May 11, 2020 12:35 PM
To: dev@nuttx.apache.org
Subject: Re: enter/leave_critical_section() calls in the user space library


>  From this link:
> https://linux.die.net/man/3/setlogmask
> logmask has per task scope not per thread scope. So we still suffer the 
> concurrent issue if we change to group-specific logmask.

The same text appears in the more authoritative Opengroup.org web page: 
https://pubs.opengroup.org/onlinepubs/7908799/xsh/closelog.html

We meet that requirement in the KERNEL mode, but not in the FLAT or PROTECTED 
modes.

So the logmask must be in the group structure and setlogmask must become a 
system call at least in the FLAT and PROTECTED build.  In the KERNEL build, a 
plain global variable as it is now is just fine.  There will be one instance of 
the global variable in each process address space.

pthread APIs are not appropriate for use across processes (groups), so we must 
avoid pthread mutexes.  This will not work in the KERNEL build mode because 
each mutex lies in a different address space.   A usable mutex would have to 
use something like sem_open() which creates a semaphore can be used across 
process boundaries.

Note that setlogmask is classified as NOT thread safe: Preliminary: | MT-Unsafe 
race:LogMask | AS-Unsafe | AC-Safe | See POSIX Safety Concepts 
<https://www.gnu.org/software/libc/manual/html_node/POSIX-Safety-Concepts.html#POSIX-Safety-Concepts>.
See https://www.gnu.org/software/libc/manual/html_node/setlogmask.html

So we should have no concern about thread safety.  No re-entrancy protection is 
required.  We can just remove the critical section. We do not need to use a 
semaphore or mutex.

Greg


Reply via email to