Posix semaphores : Doubt

[Joel Sherrill]

sashti srinivasan wrote:

> Hello,
> 
>      I have a few doubts about using POSIX semaphores.
>  May I have some suggestions on these?
> 
> (1)  If I configure for a maximum of N semaphores,
> does it mean that I can call sem_init() only N times
> or (Number of calls to sem_init)- (Number of calls to
> sem_destroy) should be less than N at any point in
> time during execution?
> 
> (2) If the latter is correct, one of the calls to
> sem_init() returns ENOSPC.  What are the possible
> reasons?  If this is discussed somewhere, please give
> me pointers.

Since the code is boiler plate for creating the manager
with N objects, my first guess would be that you did not
actually destroy it.  That could be because you passed in
a bad ID. Looking at the sem_init and sem_destroy code,
there isn't much that can go wrong if all you are doing
is:

   loop
      sem_init
      sem_destroy

Are you checking the sem_destroy status?

Finally, you have the source, step into the calls and see
if you can tell which direction things are going.  That
at least is better than asking us to shoot in the dark.

> (3) Times for various mutex and semaphore operations
> vary significantly.  Please suggest a reason why these
> operations do not take deterministic amount of time.

You don't say which operations, configuration, or
anything else.  Create and delete take more time
than obtain/release.  If you block or get preempted, times
will be more than not having to block.

In truth, the POSIX semaphore code is a simple wrapper
on top of the core semaphore and as far as I can tell
none of the operations has anything but constant order
algorithms.  If you block it takes longer than not blocking
but that time is always the same.

POSIX semaphores also FIFO blocking which means that it is a
very simple fixed time algorithm.

Also all it takes in your test scenario is getting a
clock tick and getting preempted to skew the times.
The RTEMS tmtests do not even initialize a clock tick
source to avoid this perturbance.

I and others have asked before but are you sure that
your timer code is accurate and linear?  Do the
times reported for various number of simple loop
iterations scale correctly?

for (i=0 ; i<MAX ; i++ )
   null_func();

time that for values of MAX like 1, 10, 1000, 100000,
1,000,000, 10,000,000 and possibly even larger to
see that your timer is working like you think.

The RTEMS tmtest tmck also has code to see how much
variation there is in timing the same thing.  See
the function check_read_timer().  You might be
surprised how much variation there is.

--joel



> With Regards
> Srinivasan
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway 
> http://promotions.yahoo.com/design_giveaway/