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
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 process
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 o
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 N
Why does a rarely called function need to be inline?
> Testing whether a process is (currently) done by checking whether the
> process's thread list has a single item. This is currently done in just
> two places, but I expect to need this in more places, so let's abstract
> that into an inlin
"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 runnin
> > Is there any good option for debugging a multithreaded program?
>
> By defenition there isn't. Anything you do will affect the timing of
> your program. If you want debugability, avoid threads.
Race-free parallel programming is an active area of research. I can't
accept your definition be
