source: rtems/cpukit/posix/src/condtimedwait.c @ d17c114

Last change on this file since d17c114 was d17c114, checked in by Joel Sherrill <joel.sherrill@…>, on 07/24/08 at 20:43:24

2008-07-24 Joel Sherrill <joel.sherrill@…>

PR 1291/cpukit

  • posix/src/posixtimespecabsolutetimeout.c: New file.
  • itron/inline/rtems/itron/semaphore.inl, itron/src/twai_sem.c, posix/Makefile.am, posix/include/mqueue.h, posix/include/rtems/posix/mqueue.h, posix/include/rtems/posix/semaphore.h, posix/include/rtems/posix/time.h, posix/src/condtimedwait.c, posix/src/mqueuereceive.c, posix/src/mqueuerecvsupp.c, posix/src/mqueuesend.c, posix/src/mqueuesendsupp.c, posix/src/mqueuetimedreceive.c, posix/src/mqueuetimedsend.c, posix/src/mutexfromcorestatus.c, posix/src/mutextimedlock.c, posix/src/semaphorewaitsupp.c, posix/src/semtimedwait.c, posix/src/semtrywait.c, posix/src/semwait.c, rtems/src/semobtain.c, rtems/src/semtranslatereturncode.c, score/include/rtems/score/coresem.h, score/src/coremsgseize.c, score/src/coresemseize.c: This patch addresses issues on implementation of the timeout on the following POSIX services. Some of these services incorrectly took a timeout as a relative time. Others would compute a 0 delta to timeout if the absolute time and the current time were equal and thus incorrectly block the caller forever. The root of the confusion is that POSIX specifies that if the timeout is incorrect (e.g. in the past, is now, or is numerically invalid), that it does not matter if the call would succeed without blocking. This is in contrast to RTEMS programming style where all errors are checked before any critical sections are entered. This fix implemented a more uniform way of handling POSIX absolute time timeouts.

+ pthread_cond_timedwait - could block forever
+ mq_timedreceive - used relative not absolute time
+ mq_timedsend - used relative not absolute time
+ pthread_mutex_timedlock - used relative not absolute time
+ pthread_rwlock_timedrdlock- used relative not absolute time
+ pthread_rwlock_timedwrlock- used relative not absolute time
+ sem_timedwait - could block forever
  • Property mode set to 100644
File size: 1.5 KB
Line 
1/*
2 *  $Id$
3 */
4
5#if HAVE_CONFIG_H
6#include "config.h"
7#endif
8
9#include <pthread.h>
10#include <errno.h>
11
12#include <rtems/system.h>
13#include <rtems/score/object.h>
14#include <rtems/score/states.h>
15#include <rtems/score/watchdog.h>
16#include <rtems/posix/cond.h>
17#include <rtems/posix/time.h>
18#include <rtems/posix/mutex.h>
19
20/*PAGE
21 *
22 *  11.4.4 Waiting on a Condition, P1003.1c/Draft 10, p. 105
23 */
24
25int pthread_cond_timedwait(
26  pthread_cond_t        *cond,
27  pthread_mutex_t       *mutex,
28  const struct timespec *abstime
29)
30{
31  Watchdog_Interval ticks;
32  boolean           already_timedout;
33
34  /*
35   *  POSIX requires that blocking calls with timeouts that take
36   *  an absolute timeout must ignore issues with the absolute
37   *  time provided if the operation would otherwise succeed.
38   *  So we check the abstime provided, and hold on to whether it
39   *  is valid or not.  If it isn't correct and in the future,
40   *  then we do a polling operation and convert the UNSATISFIED
41   *  status into the appropriate error.
42   */
43  switch ( _POSIX_Absolute_timeout_to_ticks(abstime, &ticks) ) {
44    case POSIX_ABSOLUTE_TIMEOUT_INVALID:
45      return EINVAL;
46    case POSIX_ABSOLUTE_TIMEOUT_IS_IN_PAST:
47    case POSIX_ABSOLUTE_TIMEOUT_IS_NOW:
48      already_timedout = TRUE;
49      break;
50    case POSIX_ABSOLUTE_TIMEOUT_IS_IN_FUTURE:
51      already_timedout = FALSE;
52      break;
53  }
54
55  return _POSIX_Condition_variables_Wait_support(
56    cond,
57    mutex,
58    ticks,
59    already_timedout
60  );
61}
Note: See TracBrowser for help on using the repository browser.