2 files changed, 40 insertions, 18 deletions

diff --git a/newlib/libc/stdlib/envlock.c b/newlib/libc/stdlib/envlock.c
index 8e55de288..24d0083be 100644
--- a/newlib/libc/stdlib/envlock.c
+++ b/newlib/libc/stdlib/envlock.c
@@ -9,24 +9,24 @@ INDEX
 
 ANSI_SYNOPSIS
 	#include "envlock.h"
-       void __env_lock (struct _reent *<[reent]>);
-       void __env_unlock (struct _reent *<[reent]>);
+	void __env_lock (struct _reent *<[reent]>);
+	void __env_unlock (struct _reent *<[reent]>);
 
 TRAD_SYNOPSIS
 	void __env_lock(<[reent]>)
-       struct _reent *<[reent]>;
+	struct _reent *<[reent]>;
 
 	void __env_unlock(<[reent]>)
-       struct _reent *<[reent]>;
+	struct _reent *<[reent]>;
 
 DESCRIPTION
-The <<setenv>> family of routines call these functions when they need
-to modify the environ variable.  The version of these routines supplied
-in the library does not do anything.  If multiple threads of execution
-can call <<setenv>>, or if <<setenv>> can be called reentrantly, then
-you need to define your own versions of these functions in order to
-safely lock the memory pool during a call.  If you do not, the memory
-pool may become corrupted.
+The <<setenv>> family of routines call these functions when they need to
+modify the environ variable.  The version of these routines supplied in the
+library use the lock API defined in sys/lock.h.  If multiple threads of
+execution can call <<setenv>>, or if <<setenv>> can be called reentrantly,
+then you need to define your own versions of these functions in order to
+safely lock the memory pool during a call.  If you do not, the memory pool
+may become corrupted.
 
 A call to <<setenv>> may call <<__env_lock>> recursively; that is,
 the sequence of calls may go <<__env_lock>>, <<__env_lock>>,
@@ -36,16 +36,26 @@ that it already holds.
 */
 
 #include "envlock.h"
+#include <sys/lock.h>
 
+#ifndef __SINGLE_THREAD__
+__LOCK_INIT_RECURSIVE(static, __env_lock_object);
+#endif
 
 void
 __env_lock (ptr)
      struct _reent *ptr;
 {
+#ifndef __SINGLE_THREAD__
+  __lock_acquire_recursive (__env_lock_object);
+#endif
 }
 
 void
 __env_unlock (ptr)
      struct _reent *ptr;
 {
+#ifndef __SINGLE_THREAD__
+  __lock_release_recursive (__env_lock_object);
+#endif
 }
diff --git a/newlib/libc/stdlib/mlock.c b/newlib/libc/stdlib/mlock.c
index c603fbcda..378b4e691 100644
--- a/newlib/libc/stdlib/mlock.c
+++ b/newlib/libc/stdlib/mlock.c
@@ -21,13 +21,13 @@ TRAD_SYNOPSIS
 	struct _reent *<[reent]>;
 
 DESCRIPTION
-The <<malloc>> family of routines call these functions when they need
-to lock the memory pool.  The version of these routines supplied in
-the library does not do anything.  If multiple threads of execution
-can call <<malloc>>, or if <<malloc>> can be called reentrantly, then
-you need to define your own versions of these functions in order to
-safely lock the memory pool during a call.  If you do not, the memory
-pool may become corrupted.
+The <<malloc>> family of routines call these functions when they need to lock
+the memory pool.  The version of these routines supplied in the library use
+the lock API defined in sys/lock.h.  If multiple threads of execution can
+call <<malloc>>, or if <<malloc>> can be called reentrantly, then you need to
+define your own versions of these functions in order to safely lock the
+memory pool during a call.  If you do not, the memory pool may become
+corrupted.
 
 A call to <<malloc>> may call <<__malloc_lock>> recursively; that is,
 the sequence of calls may go <<__malloc_lock>>, <<__malloc_lock>>,
@@ -37,16 +37,28 @@ that it already holds.
 */
 
 #include <malloc.h>
+#include <sys/lock.h>
+
+#ifndef __SINGLE_THREAD__
+__LOCK_INIT_RECURSIVE(static, __malloc_lock_object);
+#endif
 
 void
 __malloc_lock (ptr)
      struct _reent *ptr;
 {
+#ifndef __SINGLE_THREAD__
+  __lock_acquire_recursive (__malloc_lock_object);
+#endif
 }
 
 void
 __malloc_unlock (ptr)
      struct _reent *ptr;
 {
+#ifndef __SINGLE_THREAD__
+  __lock_release_recursive (__malloc_lock_object);
+#endif
 }
+
 #endif