Where to put arch-dependant locking in malloc/thread-m.h
RFC 1/1 Where to put arch-dependant locking in malloc/thread-m.h
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.
malloc/thread-m.h +22 -0
@@ -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) \
Hi,
Quoted 3 lines
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?
Ok, I have become convinced it is best to move thread-m.h into sysdeps. We should rename it, too (my suggestion: malloc-machine.h), and make sure that one can put e.g.
#define DEFAULT_MMAP_THRESHOLD (256*1024)
in there and have it reflected in malloc.
I'll send a patch for this tomorrow.
Regards,
Wolfram.
Hi,
Quoted 3 lines
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?
Ok, I have become convinced it is best to move thread-m.h into sysdeps. We should rename it, too (my suggestion: malloc-machine.h), and make sure that one can put e.g.
#define DEFAULT_MMAP_THRESHOLD (256*1024)
in there and have it reflected in malloc.
I'll send a patch for this tomorrow.
Regards,
Wolfram.
Quoted 8 lines · On Fri, Sep 26, 2003 at 01:39:54PM -0000, [email protected] wrote:
Quoted 3 lines
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?Ok, I have become convinced it is best to move
thread-m.hinto sysdeps. We should rename it, too (my suggestion:malloc-machine.h), and make sure that one can put e.g.
Quoted 5 lines
#define
DEFAULT_MMAP_THRESHOLD(256*1024)in there and have it reflected in malloc.
I'll send a patch for this tomorrow.
Thank you. Sounds like the best solution in this case.
c.
Quoted 8 lines · On Fri, Sep 26, 2003 at 01:39:54PM -0000, [email protected] wrote:
Quoted 3 lines
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?Ok, I have become convinced it is best to move
thread-m.hinto sysdeps. We should rename it, too (my suggestion:malloc-machine.h), and make sure that one can put e.g.
Quoted 5 lines
#define
DEFAULT_MMAP_THRESHOLD(256*1024)in there and have it reflected in malloc.
I'll send a patch for this tomorrow.
Thank you. Sounds like the best solution in this case.
c.