native vs posix threads mess

native vs posix threads mess

[J.A. Magallon]

Hi all...

This are just some comments, to see if somebody has any idea that can guide me
to make things the more 'linux' way...

Everybody says that POSIX threads in Linux suck. Well, I trusted them and begun
to order my ideas with clone() and make some tests. Easy things are easy.

Then you want mutexes. Try with semaphores. Use POSIX semaphores, look like more
standard. After some digging (manual page says nothing) and a couple of
failed links, I discover this:

werewolf:~/aleph/ask/lib/include/ast> cat /usr/lib/librt.so
/* GNU ld script
   librt.so.1 needs libpthread.so.0 to come before libc.so.6*
   in search scope.  */
GROUP ( /lib/libpthread.so.0 /lib/librt.so.1 )

So I can't get rid of -lpthread (and its <in>famous kernel call overriding).
Semaphores are implemented on top of POSIX threads ? Grr....
And I can not share sem_t over clone(). So what is it useful for ????

Lets try with SystemV. At least they resolve directly in libc.

People talk bad about pthreads, but looks like the only piece of order here.
If you do threads with clone(), how would you get mutexes and semaphores
and so on the 'linux' way ?

TIA

-- 
J.A. Magallon             \   Software is like sex: It's better when it's free
mailto:jamagallon@able.es  \                    -- Linus Torvalds, FSF T-shirt
Linux werewolf 2.4.19-rc1-jam3, Mandrake Linux 8.3 (Cooker) for i586
gcc (GCC) 3.1.1 (Mandrake Linux 8.3 3.1.1-0.7mdk)

Re: native vs posix threads mess

[Robert M. Hyatt]

On Sun, 14 Jul 2002, J.A. Magallon wrote:

> Hi all...
> 
> This are just some comments, to see if somebody has any idea that can guide me
> to make things the more 'linux' way...
> 
> Everybody says that POSIX threads in Linux suck. Well, I trusted them and begun
> to order my ideas with clone() and make some tests. Easy things are easy.
> 
> Then you want mutexes. Try with semaphores. Use POSIX semaphores, look like more
> standard. After some digging (manual page says nothing) and a couple of
> failed links, I discover this:
> 
> werewolf:~/aleph/ask/lib/include/ast> cat /usr/lib/librt.so
> /* GNU ld script
>    librt.so.1 needs libpthread.so.0 to come before libc.so.6*
>    in search scope.  */
> GROUP ( /lib/libpthread.so.0 /lib/librt.so.1 )
> 
> So I can't get rid of -lpthread (and its <in>famous kernel call overriding).
> Semaphores are implemented on top of POSIX threads ? Grr....
> And I can not share sem_t over clone(). So what is it useful for ????
> 
> Lets try with SystemV. At least they resolve directly in libc.
> 
> People talk bad about pthreads, but looks like the only piece of order here.
> If you do threads with clone(), how would you get mutexes and semaphores
> and so on the 'linux' way ?


First, you can steal the kernel atomic lock (based on the exchange
instruction).  That works _perfect_ when you want a spin-lock.  If you
want a mutex, there are several ways to roll your own, assuming you
really want to block when a lock is set.

IF I wanted to do this, I would try the kernel spinlock approach,
but include a counter so it is only executed N times before giving
up.  Upon giving up, I would then put myself on a wake-up queue
(locking that carefully as well) and then block myself.  When a
thread unsets the lock, it would check the wake-up queue and if
a thread is waiting, it could be woken up any way you want.

Posix threads are not bad.  But someone did something bad in the
glibc stuff and broke it for me (using the chess program Crafty).
I ran forever on redhat 6.2 and gcc 2.95.2...  when I tried
redhat 7.x (x=0,1,2 or 3) crafty breaks instantly.  The "control
thread" (pthreads starts one extra thread to collect exit status
and do other bookkeeping) crashes instantly which breaks everything.

clone() works perfectly for me, and since I didn't use mutexes
anyway (I only lock for _very_ short periods of time) getting rid
of posix threads under linux was trivial.



> 
> TIA
> 
> 

-- 
Robert Hyatt                    Computer and Information Sciences
hyatt@cis.uab.edu               University of Alabama at Birmingham
(205) 934-2213                  115A Campbell Hall, UAB Station 
(205) 934-5473 FAX              Birmingham, AL 35294-1170

Re: native vs posix threads mess

[E. Robert Bogusta]

On Sat, 13 Jul 2002, Robert M. Hyatt wrote:

Yes, this is very belated, it just struck me.

> On Sun, 14 Jul 2002, J.A. Magallon wrote:
> 
> > Hi all...
> > 
> > This are just some comments, to see if somebody has any idea that can guide me
> > to make things the more 'linux' way...
> > 
> > Everybody says that POSIX threads in Linux suck. Well, I trusted them and begun
> > to order my ideas with clone() and make some tests. Easy things are easy.
> > 
> > Then you want mutexes. Try with semaphores. Use POSIX semaphores, look like more
> > standard. After some digging (manual page says nothing) and a couple of
> > failed links, I discover this:

> Posix threads are not bad.  But someone did something bad in the
> glibc stuff and broke it for me (using the chess program Crafty).
> I ran forever on redhat 6.2 and gcc 2.95.2...  when I tried
> redhat 7.x (x=0,1,2 or 3) crafty breaks instantly.  The "control
> thread" (pthreads starts one extra thread to collect exit status
> and do other bookkeeping) crashes instantly which breaks everything.

Have you tried NGPT, now that they are supported in the recent kernels.
Based on limited experience I would say that they have run any little
thing which works on Solaris. One of these days I'll try BSD and see what
the threading is like there.

-- 
rob bogus