Re: [ECOS] FW: [ECOS] binary semaphores from counting or mutex

[Nick Garnett <nickg at ecoscentric dot com>]

"Aaron Case" <aaron.case@dynazign.com> writes:

> -----Original Message-----
> From: Aaron Case [mailto:aaron.case@dynazign.com]
> Sent: Thursday, August 14, 2003 2:29 PM
> To: sandeep
> Subject: RE: [ECOS] binary semaphores from counting or mutex
> 
> 
> Sandeep,
> 
> This is a single processor system, EP7312.
> 
> Company policy prohibits mailing any code, but its very simple test as
> follows...
> 
> Create 4 threads that are all synchronized by one semaphore(initializied to
> a value of 1).
> 
> The threads all wait for the semaphore right out of the gate. Each thread
> consists of a infinite while loop that waits for the semaphore at the
> beginning and posts at the end of the loop with a diagnostic message
> between.
> 
> One would never code in such a way, but this does simulate a condition where
> if 4 threads executing an infinite loop all jump on one resource.
> Admittedly, a worse case scenario but, a possibility given the nature of our
> application.
> 
> This seemingly inane test always ends by "locking the keys in the car."  The
> semaphore count gets set to zero and all threads are waiting on after only
> executing the one thread once.

My interpretation of your program is at the end of this
message. Clearly you are doing something different to me since this
program runs just fine. I get the following output:

2: counts 3592675 1683894 1354903 3368528
3: counts 5557653 5052415 4112701 5277231
1: counts 9768306 8084031 4954845 7192818
0: counts 11902609 10335894 7481250 10280247
3: counts 14154103 11458757 11410800 12976340
2: counts 16960825 15387917 12984768 14666490
3: counts 18364396 16510782 16639804 18485018
2: counts 21171510 18756480 18212866 21859144
3: counts 24820353 20440367 20464549 24274731
3: counts 28469203 24369932 21867740 25293125

And so on ad infinitum. The slight unevenness in the counts is an
artefact of the nature of the program interacting with the scheduler
and timeslicing. It tends to even out over time. The business with the
counts is to minimize any effects that diag_printf() might have.

Since you are not allowed to modify this program and mail it back to
me, could you decribe how it differs from yours. This was run using
a default eCos configuration, have you changed your configuration? If
so how?

Note: I ran this on an 800MHz Pentium, you may need to reduce that
10000000 to get messages at a reasonable frequency on a slower
processor.


----------------------------------------------------------------------

#include <cyg/hal/hal_arch.h>
#include <cyg/infra/diag.h>
#include <cyg/kernel/kapi.h>

#define NTEST_THREADS   4
#define STACK_SIZE      CYGNUM_HAL_STACK_SIZE_MINIMUM

static char stacks[NTEST_THREADS][STACK_SIZE];
static cyg_thread test_threads[NTEST_THREADS];
static cyg_handle_t threads[NTEST_THREADS];

static cyg_sem_t sem;

volatile long count[NTEST_THREADS];
volatile long total;

static void entry0(cyg_addrword_t arg)
{
    while(1)
    {
        cyg_semaphore_wait( &sem );

        count[arg]++;
        total++;
        if( (total % 10000000) == 0 )
            diag_printf("%d: counts %d %d %d %d\n",arg,count[0],count[1],count[2],count[3]);

        cyg_semaphore_post( &sem );
    }
}

externC void
cyg_start( void )
{
    int i;

    cyg_semaphore_init( &sem, 1 );
    
    for (i = 0;  i < NTEST_THREADS;  i++)
    {
        cyg_thread_create(10,              // Priority - just a number
                          entry0,          // entry
                          i,               // index
                          NULL,            // Name
                          &stacks[i][0],   // Stack
                          STACK_SIZE,      // Size
                          &threads[i],     // Handle
                          &test_threads[i] // Thread data structure
            );
        cyg_thread_resume(threads[i]);
    }

    cyg_scheduler_start();
}


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss