musl/include/semaphore.h

40 lines
810 B
C
Raw Normal View History

2011-02-12 05:22:29 +00:00
#ifndef _SEMAPHORE_H
#define _SEMAPHORE_H
#ifdef __cplusplus
extern "C" {
#endif
#include <features.h>
#define __NEED_time_t
#define __NEED_struct_timespec
#include <bits/alltypes.h>
#include <fcntl.h>
2011-02-12 05:22:29 +00:00
#define SEM_FAILED ((sem_t *)0)
typedef struct {
make all objects used with atomic operations volatile the memory model we use internally for atomics permits plain loads of values which may be subject to concurrent modification without requiring that a special load function be used. since a compiler is free to make transformations that alter the number of loads or the way in which loads are performed, the compiler is theoretically free to break this usage. the most obvious concern is with atomic cas constructs: something of the form tmp=*p;a_cas(p,tmp,f(tmp)); could be transformed to a_cas(p,*p,f(*p)); where the latter is intended to show multiple loads of *p whose resulting values might fail to be equal; this would break the atomicity of the whole operation. but even more fundamental breakage is possible. with the changes being made now, objects that may be modified by atomics are modeled as volatile, and the atomic operations performed on them by other threads are modeled as asynchronous stores by hardware which happens to be acting on the request of another thread. such modeling of course does not itself address memory synchronization between cores/cpus, but that aspect was already handled. this all seems less than ideal, but it's the best we can do without mandating a C11 compiler and using the C11 model for atomics. in the case of pthread_once_t, the ABI type of the underlying object is not volatile-qualified. so we are assuming that accessing the object through a volatile-qualified lvalue via casts yields volatile access semantics. the language of the C standard is somewhat unclear on this matter, but this is an assumption the linux kernel also makes, and seems to be the correct interpretation of the standard.
2015-03-04 03:50:02 +00:00
volatile int __val[4*sizeof(long)/sizeof(int)];
2011-02-12 05:22:29 +00:00
} sem_t;
int sem_close(sem_t *);
int sem_destroy(sem_t *);
int sem_getvalue(sem_t *__restrict, int *__restrict);
2011-02-12 05:22:29 +00:00
int sem_init(sem_t *, int, unsigned);
sem_t *sem_open(const char *, int, ...);
int sem_post(sem_t *);
int sem_timedwait(sem_t *__restrict, const struct timespec *__restrict);
2011-02-12 05:22:29 +00:00
int sem_trywait(sem_t *);
int sem_unlink(const char *);
int sem_wait(sem_t *);
add time64 symbol name redirects to public headers, under arch control a _REDIR_TIME64 macro is introduced, which the arch's alltypes.h is expected to define, to control redirection of symbol names for interfaces that involve time_t and derived types. this ensures that object files will only be linked to libc interfaces matching the ABI whose headers they were compiled against. along with time32 compat shims, which will be introduced separately, the redirection also makes it possible for a single libc (static or shared) to be used with object files produced with either the old (32-bit time_t) headers or the new ones after 64-bit time_t switchover takes place. mixing of such object files (or shared libraries) in the same program will also be possible, but must be done with care; ABI between libc and a consumer of the libc interfaces is guaranteed to match by the the symbol name redirection, but pairwise ABI between consumers of libc that define interfaces between each other in terms of time_t is not guaranteed to match. this change adds a dependency on an additional "GNU C" feature to the public headers for existing 32-bit archs, which is generally undesirable; however, the feature is one which glibc has depended on for a long time, and thus which any viable alternative compiler is going to need to provide. 64-bit archs are not affected, nor will future 32-bit archs be, regardless of whether they are "new" on the kernel side (e.g. riscv32) or just newly-added (e.g. a new sparc or xtensa port). the same applies to newly-added ABIs for existing machine-level archs.
2019-07-31 19:24:58 +00:00
#if _REDIR_TIME64
__REDIR(sem_timedwait, __sem_timedwait_time64);
#endif
2011-02-12 05:22:29 +00:00
#ifdef __cplusplus
}
#endif
#endif