All of lore.kernel.org
 help / color / mirror / Atom feed
* [parisc-linux] [RFC] Where to put arch-dependant locking in malloc/thread-m.h
@ 2003-09-25 21:15 Carlos O'Donell
  2003-09-26 13:39 ` [parisc-linux] " wmglo
  2003-09-26 13:39 ` wmglo
  0 siblings, 2 replies; 6+ messages in thread
From: Carlos O'Donell @ 2003-09-25 21:15 UTC (permalink / raw)
  To: libc-alpha; +Cc: parisc-linux

libc,

Found the problem with bug-iconv3, it was related to the fact that
hppa's locks can't be initialized to zero (or left unitialized). When
running a non-threaded application and dlopening libpthread the
__libc_maybe_call2's start using the proper strong symbol of those
funcions. At this point malloc on hppa would in certain occassions
fget stuck in a lock that it thought was taken (value of zero).

The following patch fixes the issue, but I'm not content about it's
placement in malloc/thread-m.h. Any comments about where I might put
this in order to make maintenance easier?

Cheers,
Carlos.

diff -u -p -r1.23 thread-m.h
--- glibc/malloc/thread-m.h	1 Jul 2003 08:29:43 -0000	1.23
+++ glibc/malloc/thread-m.h	25 Sep 2003 20:43:55 -0000
@@ -59,6 +59,28 @@ __libc_lock_define (typedef, mutex_t)
 #define mutex_unlock(m)		\
   __libc_maybe_call2 (pthread_mutex_unlock, (m), (*(int *)(m) = 0))
 
+# if(defined __hppa__)
+/* Since our lock structure does not tolerate being initialized to zero, we must
+   modify the standard function calls made by malloc */
+#  undef mutex_init
+#  undef mutex_lock
+#  undef mutex_trylock
+#  undef mutex_unlock
+#  define mutex_init(m)		\
+	__libc_maybe_call (__pthread_mutex_init, (m, NULL), \
+			(((m)->__m_lock.__spinlock = __LT_SPINLOCK_INIT),(*(int *)(m))) )
+#  define mutex_lock(m)		\
+	__libc_maybe_call (__pthread_mutex_lock, (m), \
+			(__load_and_clear(&((m)->__m_lock.__spinlock)), 0))
+#  define mutex_trylock(m)	\
+	__libc_maybe_call (__pthread_mutex_trylock, (m), \
+			(*(int *)(m) ? 1 : (__load_and_clear(&((m)->__m_lock.__spinlock)), 0)))
+#  define mutex_unlock(m)	\
+	__libc_maybe_call (__pthread_mutex_unlock, (m), \
+			(((m)->__m_lock.__spinlock = __LT_SPINLOCK_INIT), (*(int *)(m))) )
+# endif 
+/* if(defined __hppa__) */
+	
 #else
 
 #define mutex_init(m)		\

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [parisc-linux] [RFC] Where to put arch-dependant locking in malloc/thread-m.h
@ 2003-09-25 21:15 Carlos O'Donell
  0 siblings, 0 replies; 6+ messages in thread
From: Carlos O'Donell @ 2003-09-25 21:15 UTC (permalink / raw)
  To: libc-alpha; +Cc: parisc-linux

libc,

Found the problem with bug-iconv3, it was related to the fact that
hppa's locks can't be initialized to zero (or left unitialized). When
running a non-threaded application and dlopening libpthread the
__libc_maybe_call2's start using the proper strong symbol of those
funcions. At this point malloc on hppa would in certain occassions
fget stuck in a lock that it thought was taken (value of zero).

The following patch fixes the issue, but I'm not content about it's
placement in malloc/thread-m.h. Any comments about where I might put
this in order to make maintenance easier?

Cheers,
Carlos.

diff -u -p -r1.23 thread-m.h
--- glibc/malloc/thread-m.h	1 Jul 2003 08:29:43 -0000	1.23
+++ glibc/malloc/thread-m.h	25 Sep 2003 20:43:55 -0000
@@ -59,6 +59,28 @@ __libc_lock_define (typedef, mutex_t)
 #define mutex_unlock(m)		\
   __libc_maybe_call2 (pthread_mutex_unlock, (m), (*(int *)(m) = 0))
 
+# if(defined __hppa__)
+/* Since our lock structure does not tolerate being initialized to zero, we must
+   modify the standard function calls made by malloc */
+#  undef mutex_init
+#  undef mutex_lock
+#  undef mutex_trylock
+#  undef mutex_unlock
+#  define mutex_init(m)		\
+	__libc_maybe_call (__pthread_mutex_init, (m, NULL), \
+			(((m)->__m_lock.__spinlock = __LT_SPINLOCK_INIT),(*(int *)(m))) )
+#  define mutex_lock(m)		\
+	__libc_maybe_call (__pthread_mutex_lock, (m), \
+			(__load_and_clear(&((m)->__m_lock.__spinlock)), 0))
+#  define mutex_trylock(m)	\
+	__libc_maybe_call (__pthread_mutex_trylock, (m), \
+			(*(int *)(m) ? 1 : (__load_and_clear(&((m)->__m_lock.__spinlock)), 0)))
+#  define mutex_unlock(m)	\
+	__libc_maybe_call (__pthread_mutex_unlock, (m), \
+			(((m)->__m_lock.__spinlock = __LT_SPINLOCK_INIT), (*(int *)(m))) )
+# endif 
+/* if(defined __hppa__) */
+	
 #else
 
 #define mutex_init(m)		\

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-09-26 14:29 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-09-25 21:15 [parisc-linux] [RFC] Where to put arch-dependant locking in malloc/thread-m.h Carlos O'Donell
2003-09-26 13:39 ` [parisc-linux] " wmglo
2003-09-26 13:39 ` wmglo
2003-09-26 14:24   ` Carlos O'Donell
2003-09-26 14:24   ` Carlos O'Donell
  -- strict thread matches above, loose matches on Subject: below --
2003-09-25 21:15 [parisc-linux] " Carlos O'Donell

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.