🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.next.programmer
3 messages
3 total messages Started by Patrick Stein Tue, 06 Oct 1992 18:36
another KERNEL BUG : SLOW THREADS
#1760
Author: Patrick Stein
Date: Tue, 06 Oct 1992 18:36
113 lines
3627 bytes
/*

Hiho again from munich B)


I posted the mach kernel bug , but nobody answered B(

So if you don't believe me ... test this program under NS2.1 and NS3.0
It's unbelievable slow under 3.O. WHY ???
Didn't NeXT remove the DEBUG Messages ?????
My first thought was, that the mutex_unlock,mutex_lock and the conditon_*
functions are so slow : There are not slow, the cthread_detach(cthread_fork...
is the major speed problem. 
I need a fast thread execution time, so i will be very very very inter-
ested in hints or improvements to solve that situation.

					Jolly




post scriptum : the program can be found in the DL too ( only the number of
		threads changed )


*/

#include <stdio.h> 
#include <cthreads.h>

int         count;    /* number of slave threads active */ 
mutex_t     lock;     /* mutual exclusion for count */ 
mutex_t     print;    /* mutual exclusion for printfs */ 
condition_t done;     /* signaled each time a slave thread finishes */

void init() 
{ 
    /* Allocate mutex variables "lock" and "print". */     
    lock = mutex_alloc();    
    print = mutex_alloc(); 

    /* Allocate condition variable "done". */     
    done = condition_alloc(); 

    count = 0; 
}

/*
 * Each slave just loops, yielding the processor on each 
 * iteration.  When it's finished, it decrements the global 
 * count and signals that it's done.  
 */ 
void slave(int n) 
{ 
    int i;

    for (i = 0; i < 100; i += 1) 
        cthread_yield(); 

    /*
     * If any thread wants to access the count variable, it      
     * first locks the mutex.  When the mutex is locked, any      
     * other thread wanting the count variable must wait until      
     * the mutex is unlocked.  
     */ 
    mutex_lock(lock); 
    count -= 1; 
    mutex_lock(print);
    printf("Slave %d finished.\n", n); 
    mutex_unlock(print);
    /* Signal that this slave has finished. */ 
    condition_signal(done);    
    mutex_unlock(lock); 
}

/*
 * The master spawns a given number of slaves and then waits 
 * for them all to finish.  
 */ 
void master(int nslaves) 
{ 
    int i;

    for (i = 1; i <= nslaves; i++) { 
        mutex_lock(lock); 
        /* Increment count with the creation of each slave thread.  */ 
        count += 1; 
        /* Fork a slave and detach it.  */ 
        cthread_detach(cthread_fork((cthread_fn_t)slave, (any_t)i)); 
        mutex_unlock(lock); 
    } 

    mutex_lock(lock); 
    /*
     * Master thread loops waiting on the condition done.  Each      
     * time the master thread is signaled by a condition_signal      
     * call, it tests the count for a value of zero.  
     */ 
    while (count != 0) 
        condition_wait(done, lock); 
    mutex_unlock(lock); 

    mutex_lock(print);
    printf("All %d slaves have finished.\n", nslaves); 
    mutex_unlock(print);
    cthread_exit(0); 
}

main() 
{ 
    init(); 
    master(150);  /* Create master thread and 15 slaves. */ 
}
Re: another KERNEL BUG : SLOW THREADS
#1762
Author: Stuart Ritchie
Date: Wed, 07 Oct 1992 00:25
49 lines
2340 bytes
In article <1992Oct6.183610.17142@news.lrz-muenchen.de> jolly@next3.cis.uni-muenchen.de (Patrick Stein) writes:
>/*
>
>Hiho again from munich B)
>
>
>I posted the mach kernel bug , but nobody answered B(
>
>So if you don't believe me ... test this program under NS2.1 and NS3.0
>It's unbelievable slow under 3.O. WHY ???
>Didn't NeXT remove the DEBUG Messages ?????
>My first thought was, that the mutex_unlock,mutex_lock and the conditon_*
>functions are so slow : There are not slow, the cthread_detach(cthread_fork...
>is the major speed problem. 
>I need a fast thread execution time, so i will be very very very inter-
>ested in hints or improvements to solve that situation.
>
>					Jolly

Yep, looks like you've found something interesting here.
I compiled and ran your program on a 2.1 and 3.0 machine.
Here are the results.

2.1 machine: 25MHz mono slab, 20MB RAM
carib [3] % time a.out
...
All 150 slaves have finished.
1.4u 2.6s 0:04 92% 0+0k 4+0io 0pf+0w

3.0 machine: 25MHz mono slab, 32MB RAM
bowen [4] % time a.out      
...
All 150 slaves have finished.
2.16u 50.734s 2:09 98% 0+0k 0+0io 0pf+0w

By reducing the number of threads created, I noticed
a dropoff point. 100 threads:62sec, 75 threads:40sec, 50 threads:5sec.
(I tried to find a similar dropoff for 2.1, but the buggy kernel
crashes the machine when too many threads are created.)

My guess is that the kernel in 3.0 is not designed to handle a
large number of threads.  Perhaps they are doing some dynamic
allocation and garbage collection when some threshold is reached.

I would be very interested in hearing something from NeXT
about these observed results.  My area is operating systems,
and I'm implementing a kernel of my own.

...Stuart
Re: another KERNEL BUG : SLOW THREADS
#1288
Author: Klaus &
Date: Wed, 07 Oct 1992 10:37
26 lines
1548 bytes
In article <1992Oct6.183610.17142@news.lrz-muenchen.de>  
jolly@next3.cis.uni-muenchen.de (Patrick Stein) writes:
> My first thought was, that the mutex_unlock,mutex_lock and the  
conditon_*
> functions are so slow : There are not slow, the  
cthread_detach(cthread_fork...
> is the major speed problem. 
> I need a fast thread execution time, so i will be very very very inter-
> ested in hints or improvements to solve that situation.
> 
> 
>					Jolly
Hi Jolly,
I have the same problem and I'm very interested in a solution of this  
problem. I've implemented an Objective-C Linda Preprocessor, and because  
it simulates several processors by threads, my implementation has slowed  
down to only 10% performance it had under 2.1, so I'm VERY dissapointed  
and a little bit angry.
So, if someone knows a solution, please let me know.

Klaus
--
Klaus Muelheims		mulheims@infko.uni-koblenz.de
Eichenwinkel 10		(NeXTmail welcome)        
                	Voice: +49 261 86518
5760 Arnsberg 1		+49 2932 1601 
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads