summaryrefslogtreecommitdiff
path: root/src/stdio/__lockfile.c
AgeCommit message (Collapse)AuthorLines
2018-10-16move stdio locking MAYBE_WAITERS definition to stdio_impl.hRich Felker-2/+0
don't repeat definition in two places.
2018-09-18fix race condition in file lockingKaarle Ritvanen-6/+6
The condition occurs when - thread #1 is holding the lock - thread #2 is waiting for it on __futexwait - thread #1 is about to release the lock and performs a_swap - thread #3 enters the __lockfile function and manages to grab the lock before thread #1 calls __wake, resetting the MAYBE_WAITERS flag - thread #1 calls __wake - thread #2 wakes up but goes again to __futexwait as the lock is held by thread #3 - thread #3 releases the lock but does not call __wake as the MAYBE_WAITERS flag is not set This condition results in thread #2 not being woken up. This patch fixes the problem by making the woken up thread ensure that the flag is properly set before going to sleep again. Mainainer's note: This fixes a regression introduced in commit c21f750727515602a9e84f2a190ee8a0a2aeb2a1.
2018-04-18fix stdio lock dependency on read-after-free not faultingRich Felker-16/+13
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.
2012-12-10document self-synchronized destruction issue for stdio lockingRich Felker-0/+10
2011-09-21avoid setting FILE lock count when not using flockfileRich Felker-1/+1
for now this is just a tiny optimization, but later if we support cancellation from __stdio_read and __stdio_write, it will be necessary for the recusrive lock count to be zero in order for these functions to know they are responsible for unlocking the FILE on cancellation.
2011-07-30add proper fuxed-based locking for stdioRich Felker-14/+12
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-05-06reduce some ridiculously large spin countsRich Felker-1/+1
these should be tweaked according to testing. offhand i know 1000 is too low and 5000 is likely to be sufficiently high. consider trying to add futexes to file locking, too...
2011-04-17debloat: use __syscall instead of syscall where possibleRich Felker-1/+1
don't waste time (and significant code size due to function call overhead!) setting errno when the result of a syscall does not matter or when it can't fail.
2011-03-28revert some more spin optimizations that turned out to be pessimizationsRich Felker-1/+1
2011-03-24simplify and optimize FILE lock handlingRich Felker-6/+7
2011-03-20global cleanup to use the new syscall interfaceRich Felker-1/+1
2011-03-12implement flockfile api, rework stdio lockingRich Felker-0/+19