Ticket #212: envlock.diff

This patch (against rtems-ss20020301) adds support 
for libc environment locking by implementing

__ENV_LOCK() / __ENV_UNLOCK().

Author: Till Straumann <strauman@slac.stanford.edu>, 3/2002

Index: c/src/lib/libc/Makefile.am
===================================================================
RCS file: /afs/slac/g/spear/cvsrep/rtems/src/c/src/lib/libc/Makefile.am,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -c -r1.1.1.2 -r1.2
*** c/src/lib/libc/Makefile.am  2002/03/07 01:53:46     1.1.1.2
--- c/src/lib/libc/Makefile.am  2002/03/28 20:59:16     1.2
***************
*** 32,37 ****
--- 32,39 ----
  
  MALLOC_C_FILES = malloc.c mallocfreespace.c __brk.c __sbrk.c
  
+ ENVIRON_C_FILES = envlock.c
+ 
  PASSWORD_GROUP_C_FILES = getpwent.c getgrent.c
  
  TERMINAL_IDENTIFICATION_C_FILES = ctermid.c isatty.c ttyname.c ttyname_r.c
***************
*** 42,48 ****
  UNIX_LIBC_C_FILES = unixlibc.c hosterr.c
  
  COMMON_C_FILES = gxx_wrappers.c printk.c $(BASE_FS_C_FILES) \
!     $(MALLOC_C_FILES) $(TERMIOS_C_FILES) $(ERROR_C_FILES) \
      $(ASSOCIATION_C_FILES)
  
  UNIX_C_FILES = $(UNIX_LIBC_C_FILES)
--- 44,50 ----
  UNIX_LIBC_C_FILES = unixlibc.c hosterr.c
  
  COMMON_C_FILES = gxx_wrappers.c printk.c $(BASE_FS_C_FILES) \
!     $(MALLOC_C_FILES) $(ENVIRON_C_FILES) $(TERMIOS_C_FILES) $(ERROR_C_FILES) \
      $(ASSOCIATION_C_FILES)
  
  UNIX_C_FILES = $(UNIX_LIBC_C_FILES)
Index: c/src/lib/libc/envlock.c
===================================================================
RCS file: envlock.c
diff -N envlock.c
*** /dev/null   Thu Aug 24 02:00:32 2000
--- /tmp/cvsdJUa8N      Sun May  5 11:22:32 2002
***************
*** 0 ****
--- 1,79 ----
+ /*
+  *  $Id: envlock.c,v 1.2 2002/04/16 01:32:48 till Exp $
+  *
+  *  Author: Till Straumann <strauman@slac.stanford.edu>, 3/2002
+  */
+ 
+ /* provide locking for the global environment 'environ' */
+ 
+ #if HAVE_CONFIG_H
+ #include "config.h"
+ #endif
+ 
+ #include <rtems.h>
+ #include <sys/reent.h>
+ 
+ #include <assert.h>
+ 
+ /*
+  * NOTES:
+  *  - although it looks like a classical multiple-readers / single writer (MRSW)
+  *    locking problem, we still use a single lock for the following reasons:
+  *     1) newlib has no provision / hook for calling different locking routines
+  *        from setenv/putenv and getenv, respectively.
+  *     2) MRSW involves calling several semaphore-primitives, even in the most likely
+  *        case of a first-reader's access. This probably takes more CPU
+  *        time than just waiting until another reader is done; environment
+  *        access is fast.
+  *  - the lock implementation must allow nesting (same thread may call
+  *    lock-lock-unlock-unlock).
+  *  - NEWLIB-1.8.2 has an ugly BUG: if environ is NULL, _findenv_r() bails
+  *    out leaving the lock held :-(
+  *  
+  */
+ 
+ static rtems_id envLock=0;
+ 
+ static void
+ __rtems_envlock_init(void)
+ {
+ extern char                   **environ;
+ rtems_status_code     rc;
+ 
+       if (envLock) /* already initialized */
+               return;
+ 
+       assert(environ && "MUST have non-NULL 'environ' due to newlib bug");
+ 
+       rc = rtems_semaphore_create(
+               rtems_build_name('E','N','V','S'),
+               1,
+               RTEMS_BINARY_SEMAPHORE | RTEMS_PRIORITY | RTEMS_INHERIT_PRIORITY,
+               0,
+               &envLock);
+       if (RTEMS_SUCCESSFUL!=rc)
+               rtems_fatal_error_occurred(rc);
+ }
+ 
+ void
+ __env_lock(struct _reent *r)
+ {
+ /* Do lazy init */
+ if (!envLock)
+       __rtems_envlock_init();
+ /* Must not use a semaphore before multitasking is up
+  * - it will corrupt memory :-(
+  */
+ if (_Thread_Executing)
+       rtems_semaphore_obtain(envLock, RTEMS_WAIT, RTEMS_NO_TIMEOUT);
+ }
+ 
+ void
+ __env_unlock(struct _reent *r)
+ {
+ /* Must not use a semaphore before multitasking is up
+  * - it will corrupt memory :-(
+  */
+ if (_Thread_Executing)
+       rtems_semaphore_release(envLock);
+ }