fluencelabs/musl
1
0
Fork 0
mirror of https://github.com/fluencelabs/musl synced 2025-04-25 15:22:15 +00:00
Code Issues Projects Releases Wiki Activity
musl/src/stdio/ftrylockfile.c

44 lines
985 B
C
Raw Normal View History

implement flockfile api, rework stdio locking
2011-03-12 21:55:45 -05:00
#include "stdio_impl.h"
#include "pthread_impl.h"
clean up sloppy nested inclusion from pthread_impl.h this mirrors the stdio_impl.h cleanup. one header which is not strictly needed, errno.h, is left in pthread_impl.h, because since pthread functions return their error codes rather than using errno, nearly every single pthread function needs the errno constants. in a few places, rather than bringing in string.h to use memset, the memset was replaced by direct assignment. this seems to generate much better code anyway, and makes many functions which were previously non-leaf functions into leaf functions (possibly eliminating a great deal of bloat on some platforms where non-leaf functions require ugly prologue and/or epilogue).
2012-11-08 17:04:20 -05:00
#include <limits.h>
implement flockfile api, rework stdio locking
2011-03-12 21:55:45 -05:00
fix stdio lock dependency on read-after-free not faulting instead of using a waiters count, add a bit to the lock field indicating that the lock may have waiters. threads which obtain the lock after contending for it will perform a potentially-spurious wake when they release the lock.
2018-04-17 23:59:41 -04:00
#define MAYBE_WAITERS 0x40000000
fix false ownership of stdio FILEs due to tid reuse this is analogous commit fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48 which fixed the corresponding issue for mutexes. the robust list can't be used here because the locks do not share a common layout with mutexes. at some point it may make sense to simply incorporate a mutex object into the FILE structure and use it, but that would be a much more invasive change, and it doesn't mesh well with the current design that uses a simpler code path for internal locking and pulls in the recursive-mutex-like code when the flockfile API is used explicitly.
2014-08-23 23:35:10 -04:00
void __do_orphaned_stdio_locks()
{
FILE *f;
for (f=__pthread_self()->stdio_locks; f; f=f->next_locked)
a_store(&f->lock, 0x40000000);
}
void __unlist_locked_file(FILE *f)
{
if (f->lockcount) {
if (f->next_locked) f->next_locked->prev_locked = f->prev_locked;
if (f->prev_locked) f->prev_locked->next_locked = f->next_locked;
else __pthread_self()->stdio_locks = f->next_locked;
}
}
implement flockfile api, rework stdio locking
2011-03-12 21:55:45 -05:00
int ftrylockfile(FILE *f)
{
fix false ownership of stdio FILEs due to tid reuse this is analogous commit fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48 which fixed the corresponding issue for mutexes. the robust list can't be used here because the locks do not share a common layout with mutexes. at some point it may make sense to simply incorporate a mutex object into the FILE structure and use it, but that would be a much more invasive change, and it doesn't mesh well with the current design that uses a simpler code path for internal locking and pulls in the recursive-mutex-like code when the flockfile API is used explicitly.
2014-08-23 23:35:10 -04:00
pthread_t self = __pthread_self();
int tid = self->tid;
fix stdio lock dependency on read-after-free not faulting instead of using a waiters count, add a bit to the lock field indicating that the lock may have waiters. threads which obtain the lock after contending for it will perform a potentially-spurious wake when they release the lock.
2018-04-17 23:59:41 -04:00
int owner = f->lock;
if ((owner & ~MAYBE_WAITERS) == tid) {
add proper fuxed-based locking for stdio previously, stdio used spinlocks, which would be unacceptable if we ever add support for thread priorities, and which yielded pathologically bad performance if an application attempted to use flockfile on a key file as a major/primary locking mechanism. i had held off on making this change for fear that it would hurt performance in the non-threaded case, but actually support for recursive locking had already inflicted that cost. by having the internal locking functions store a flag indicating whether they need to perform unlocking, rather than using the actual recursive lock counter, i was able to combine the conditionals at unlock time, eliminating any additional cost, and also avoid a nasty corner case where a huge number of calls to ftrylockfile could cause deadlock later at the point of internal locking. this commit also fixes some issues with usage of pthread_self conflicting with __attribute__((const)) which resulted in crashes with some compiler versions/optimizations, mainly in flockfile prior to pthread_create.
2011-07-30 08:02:14 -04:00
if (f->lockcount == LONG_MAX)
implement flockfile api, rework stdio locking
2011-03-12 21:55:45 -05:00
return -1;
f->lockcount++;
return 0;
}
fix stdio lock dependency on read-after-free not faulting instead of using a waiters count, add a bit to the lock field indicating that the lock may have waiters. threads which obtain the lock after contending for it will perform a potentially-spurious wake when they release the lock.
2018-04-17 23:59:41 -04:00
if (owner < 0) f->lock = owner = 0;
if (owner || a_cas(&f->lock, 0, tid))
implement flockfile api, rework stdio locking
2011-03-12 21:55:45 -05:00
return -1;
f->lockcount = 1;
fix false ownership of stdio FILEs due to tid reuse this is analogous commit fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48 which fixed the corresponding issue for mutexes. the robust list can't be used here because the locks do not share a common layout with mutexes. at some point it may make sense to simply incorporate a mutex object into the FILE structure and use it, but that would be a much more invasive change, and it doesn't mesh well with the current design that uses a simpler code path for internal locking and pulls in the recursive-mutex-like code when the flockfile API is used explicitly.
2014-08-23 23:35:10 -04:00
f->prev_locked = 0;
f->next_locked = self->stdio_locks;
fix linked list corruption in flockfile lists commit 5345c9b884e7c4e73eb2c8bb83b8d0df20f95afb added a linked list to track the FILE streams currently locked (via flockfile) by a thread. due to a failure to fully link newly added members, removal from the list could leave behind references which could later result in writes to already-freed memory and possibly other memory corruption. implicit stdio locking was unaffected; the list is only used in conjunction with explicit flockfile locking. this bug was not present in any releases; it was introduced and fixed during the same release cycle. patch by Timo Teräs, who discovered and tracked down the bug.
2014-09-19 12:28:45 -04:00
if (f->next_locked) f->next_locked->prev_locked = f;
fix false ownership of stdio FILEs due to tid reuse this is analogous commit fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48 which fixed the corresponding issue for mutexes. the robust list can't be used here because the locks do not share a common layout with mutexes. at some point it may make sense to simply incorporate a mutex object into the FILE structure and use it, but that would be a much more invasive change, and it doesn't mesh well with the current design that uses a simpler code path for internal locking and pulls in the recursive-mutex-like code when the flockfile API is used explicitly.
2014-08-23 23:35:10 -04:00
self->stdio_locks = f;
implement flockfile api, rework stdio locking
2011-03-12 21:55:45 -05:00
return 0;
}
Reference in New Issue Copy Permalink