gdb (gdb 6.3) knows about threads but core dumps half the time
and is 10 years old.
egdb (gdb 7.6) does not work right with multithreaded programs. It
sees only one thread.
Neither supports set scheduler-locking.
Is there any good option for debugging a multithreaded program?
I'm running
Here is a diff relative of OpenBSD 5.3 to avoid taking a lock in
pthread_getspecific in the common case where storage for the key is
already allocated.
I have only tested this patch for my use case where a single key is
created once and used many times. In that case, the bottleneck I
observed is
I got an email saying unified diff is preferred, so here's a resend
in that format.
Index: rthread_tls.c
===
RCS file: /cvs/src/lib/librthread/rthread_tls.c,v
retrieving revision 1.13
diff -u -r1.13 rthread_tls.c
--- rthread_tls.c 6
I attached a program showing the slowdown. It spawns threads that call
pthread_getspecific in a tight loop. On Linux the wall clock time is
essentially constant for number of threads up to number of processors.
On OpenBSD 5.3 wall clock time increases approximately linearly with
number of
I think _spinlock is suboptimal, although that's not the real problem
as far as my code is concerned. Spinlock is a loop:
while (_atomic_lock(lock-ticket)) _sched_yield();
This causes a system call every time the lock is held by another thread.
In many cases the spinlock protects a simple
Problem in a nutshell: pthread_getspecific serializes execution of
threads using it. Without a better implementation my program doesn't
work on OpenBSD.
I am trying to port Cilk+ to OpenBSD (5.3).
Cilk+ is a multithreaded extension to C/C++. It adds some bookkeeping
operations in the prologue
