Semaphore

Kernel
1

nobody wrote on Wednesday, June 07, 2006:

Hi!
I have some doubts on semahore use for lock a resource (EEPROM).
I try to define the semaphore, let’s say in eeprom.c and initialize it:

static xSemaphoreHandle xSemaphoreEEPROM;

char eepromInit(void)
{
    vSemaphoreCreateBinary( xSemaphoreEEPROM );
    if( xSemaphoreEEPROM != NULL ) return 0;
    return 1;
}

Then, can I have two files, each one with one different task that can test the semaphore xSemaphoreEEPROM before addressing the EEPROM, like:
    …
    if( xSemaphoreTake( xSemaphoreEEPROM, ( portTickType ) timeout ) )
    {
        /* Call function to write data on eeprom… */
        xSemaphoreGive( xSemaphoreEEPROM );
    }
    …
This can lock the resource, or the last code must be included in eeprom.c like a driver:
char writeEEPROM (int addr, int n, char *data, int timeout)
{
    if( xSemaphoreTake( xSemaphoreEEPROM, ( portTickType ) timeout ) )
    {
        /* Write data… */
        xSemaphoreGive( xSemaphoreEEPROM );
    }
}

Please give me some hint about this.

2

nobody wrote on Friday, June 09, 2006:

What you say seems to be correct.   You are using the semaphore to ensure mutual exclusion of the eeprom resource.

3

nobody wrote on Friday, June 09, 2006:

I don’t have experience in these kinf of OS’s but there will eventually two task accessing the same function:

char writeEEPROM (int addr, int n, char *data, int timeout)
{
if( xSemaphoreTake( xSemaphoreEEPROM, ( portTickType ) timeout ) )
{
/* Write data… */
xSemaphoreGive( xSemaphoreEEPROM );
}
}

There is any problem when two tasks call the same function with a lock semaphore like the previous one?
Or there is a better way to do this?

4

nobody wrote on Friday, June 09, 2006:

Nope, this is exactly how semaphores should be used.