summaryrefslogtreecommitdiffstats
path: root/lib/libthr
Commit message (Collapse)AuthorAgeFilesLines
...
* Bump up the maximum number concurrent threads on x86.mtm2004-02-011-1/+1
|
* I update the rwlock code in libthr to be more standards compliant andmtm2004-01-291-12/+119
| | | | | | | | | | what do I get for my troubles? libc breaks offcourse! Reimplement a hack (in libthr) that allows libc to use rwlocks without initializing them first. The hack was reimplemented so that only a private libc version of the rwlock locking functions initializes an uninitialized rwlock. The application version will correctly fail.
* When suspending a thread if the timeout was very short ormtm2004-01-291-0/+11
| | | | | | | | | | | | | the system call got interrupted and the absolute timeout is converted to a relative timeout, it may happen that we get a negative number. In such a case, simply set the timeout to zero so that if the event that the thread wants to wait for has happened it can still return successfully, but if it hasn't happened then the thread doesn't suspend indefinitely. This should fix certain applications (including mozilla) that seem to hang indefinitely sometimes. Noticed and debugged by: Morten Johansen <root@morten-johansen.net>
* o Implement the pthread_spin_* functions in libthr.mtm2004-01-222-0/+91
| | | | o Man pages
* Refactor _pthread_mutex_initmtm2004-01-191-125/+64
| | | | | | | | | | | | o Simplify the logic by removing a lot of unnecesary nesting o Reduce the amount of local variables o Zero-out the allocated structure and get rid of all the unnecessary setting to 0 and NULL; Refactor _pthread_mutex_destroy o Simplify the logic by removing a lot of unnecesary nesting o No need to check pointer that the mutex attributes points to. Checking passed in pointer is enough.
* Implement reference counting of read-write locks. This usesmtm2004-01-193-8/+155
| | | | | | | | | | | | | | | | | a list in the thread structure to keep track of the locks and how many times they have been locked. This list is checked on every lock and unlock. The traversal through the list is O(n). Most applications don't hold so many locks at once that this will become a problem. However, if it does become a problem it might be a good idea to review this once libthr is off probation and in the optimization cycle. This fixes: o deadlock when a thread tries to recursively acquire a read lock when a writer is waiting on the lock. o a thread could previously successfully unlock a lock it did not own o deadlock when a thread tries to acquire a write lock on a lock it already owns for reading or writing [ this is admittedly not required by POSIX, but is nice to have ]
* Add an implementation of pthread_rwlock_timed{rd,wr}lock() to libthr withmtm2004-01-161-11/+54
| | | | attendant documentation.
* o We are not required to initialize an invalid rwlock. So axe all thatmtm2004-01-161-160/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | code and simply return EINVAL (which is allowed by the standard) in all those pthread functions that previously initialized it. o Refactor the pthread_rwlock_[try]rdlock() and pthread_rwlock_[try]wrlock() functions. They are now completeley condensed into rwlock_rdlock_common() and rwlock_wrlock_common(), respectively. o If the application tries to destroy an rwlock that is currently held by a thread return EBUSY where it previously went ahead and freed all resources associated with the lock. o Refactor _pthread_rwlock_init() to make it look (relatively) sane. o When obtaining a read lock on an rwlock the check for whether it would exceed the maximum allowed read locks should happen *before* we obtain the lock. o The pthread_rwlock_* functions shall *never* return EINTR, so make sure to requeue/resuspend the thread if it encounters such an error. o Make a note that pthread_rwlock_unlock() needs to ensure it holds a lock on an rwlock it tries to unlock. It will be implemented in a separate commit because it requires some additional rwlock infrastructure.
* Return ENOTSUP instead of -1.ru2004-01-151-1/+1
|
* o Implement pthread_mutex_timedlock(), which does not block indefinitely onmtm2003-12-301-0/+32
| | | | | a mutex locked by another thread. o document it: pthread_mutex_timedlock(3)
* Make it possible for the library to specify a timeout value whenmtm2003-12-303-22/+49
| | | | | | | | | | waiting on a locked mutex. This involves passing a struct timespec from the pthread mutex locking interfaces all the way down to the function that suspends the thread until the mutex is released. The timeout is assumed to be an absolute time (i.e. not relative to the current time). Also, in _thread_suspend() make the passed in timespec const.
* Don't block SIGTRAP - it makes it hard to debug programs with gdb.dfr2003-12-261-0/+1
| | | | Reviewed by: mtm
* Preparations to make libthr work in multi-threaded fork()ing applications.mtm2003-12-263-63/+81
| | | | | | | | | | | | | o Remove some code duplication between _thread_init(), which is run once to initialize libthr and the intitial thread, and pthread_create(), which initializes newly created threads, into a new function called from both places: init_td_common() o Move initialization of certain parts of libthr into a separate function. These include: - Active threads list and it's lock - Dead threads list and it's lock & condition variable - Naming and insertion of the initial thread into the active threads list.
* Remove _giant_mutex and its associated macros.mtm2003-12-152-85/+0
|
* Comment out most of pthread_setschedparam. Pthread priorities didn'tmtm2003-12-151-1/+4
| | | | | | work before anyways, and I didn't want to fix broken code I had no way of testing. It was necessary however, in order to get rid of GIANT_LOCK. Pthread priorities will have to wait a little longer to get fixed.
* When creating a pthread in the suspended state their were twomtm2003-12-151-2/+4
| | | | | | | | problems: (1) The wrong flag was being checked for in the attribute (2) The pthread's state was not being set to indicate it was suspended. Noticed by: Igor Sysoev <is@rambler-co.ru>
* Doh! Lock the thread passed in by the caller, not the current thread.mtm2003-12-121-2/+2
|
* Remove uses of GIANT_LOCK and replace with appropriate threadmtm2003-12-111-7/+12
| | | | and thread list locks.
* Take a stab at fixing some of the macro-nightmare.mtm2003-12-091-46/+23
| | | | | | PTHREAD_NEW_STATE should work as expected now: a thread marked PS_RUNNING will get sent a SIGTHR. Still more cleanups necessary.
* Fix the wrapper function around signals so that a signal handlingmtm2003-12-095-58/+57
| | | | | thread on one of the mutex or condition variable queues is removed from those queues before the real signal handler is called.
* Ugghh, cvs add the functions necessary to lock the global signal actionmtm2003-12-091-0/+91
| | | | table.
* o Add a wrapper around sigaction(2), so we can insert our own wrappermtm2003-12-093-0/+62
| | | | | around signals. o Lock the process global signal action table.
* Enable cancellation points around some syscalls.mtm2003-12-091-28/+28
|
* Use dynamic instead of static LDT allocation.mtm2003-12-021-5/+4
| | | | Approved by: re (scottl)
* Relink libc_r.a, libc_r.so and libc_r_p.so from libthr to libkse.marcel2003-09-271-12/+0
| | | | | | | | | | | On ia64, where there's no libc_r at all, libkse is now the default thread library by virtue of these links. The reasons for this change are: 1. libkse is slated to become the default thread library anyway, 2. active development and maintenance is only present for libkse, 3. GNOME and KDE, both in the process of being supported on ia64, work better with KSE; even on ia64.
* Implement _get_curthread and _set_curthread. We use GCCs builtinmarcel2003-07-241-1/+6
| | | | | function this, which expands to PAL calls (rduniq and wruniq). This needs adjustment when TLS is implemented.
* This commit was generated by cvs2svn to compensate for changes in r117783,mtm2003-07-192-0/+55
|\ | | | | | | which included commits to RCS files with non-trunk default branches.
| * The MD framework for libthr on alphamtm2003-07-192-0/+55
|
* When _PTHREADSINVARIANTS is defined SIGABRT is not includedmtm2003-07-083-2/+19
| | | | | | in the set of signals to block. Also, make the PANIC macro call abort() instead of simply exiting.
* Change all instances of THR_LOCK/UNLOCK, etc to UMTX_*.mtm2003-07-068-23/+23
| | | | | It is a more acurate description of the locks they operate on.
* There's no need for _umtxtrylock to be a separate function.mtm2003-07-063-13/+8
| | | | Roll it into the pre-existing macro that's used to call it.
* _pthread_mutex_trylock() is another internal libc function that must blockmtm2003-07-031-0/+8
| | | | signals.
* Begin making libthr async signal safe.mtm2003-07-021-2/+22
| | | | | | | | Create a private, single underscore, version of pthread_mutex_unlock for libc. pthread_mutex_lock already has one. These versions are different from the ones that applications will link against because they block all signals from the time a call to lock the mutex is made until it is successfully unlocked.
* Do not attempt to reque a thread on a mutex queue. It may be thatmtm2003-07-011-1/+1
| | | | | | | | | a thread receives a spurious wakeup from sigtimedwait(), so make sure that the call to the queueing code is called only once before entering the loop (not in the loop). This should fix some fatal errors people are seeing with messages stating the thread is already on the mutex queue. These errors may still be triggered from signal handlers; however, since that part of the code is not locked down yet.
* Axe AINC.ru2003-07-011-1/+0
| | | | Submitted by: bde
* Catchup with _thread_suspend() changes.mtm2003-06-303-3/+9
|
* Sweep through pthread locking and use the new locking primitives formtm2003-06-297-20/+21
| | | | libthr.
* Locking primitives and operations in libthr should use struct umtx,mtm2003-06-292-4/+22
| | | | | | | | | | | not spinlock_t. Spinlock_t and the associated functions and macros may require blocking signals in order for async-safe libc functions to behave appropriately in libthr. This is undesriable for libthr internal locking. So, this is the first step in completely separating libthr from libc's locking primitives. Three new macros should be used for internal libthr locking from now on: THR_LOCK, THR_TRYLOCK, THR_UNLOCK.
* In a critical section, separate the aquisition of the thread lockmtm2003-06-292-17/+27
| | | | | | | | | | | | and the disabling of signals. What we are really interested in is keeping track of recursive disabling of signals. We should not be recursively acquiring thread locks. Any such situations should be reorganized to not require a recursive lock. Separating the two out also allows us to block signals independent of acquiring thread locks. This will be needed in libthr in the near future when we put the pieces together to protect libc functions that use pthread mutexes and low level locks.
* Make _thread_suspend work with both the old broken sigtimedwaitjdp2003-06-293-11/+31
| | | | | | implementation and the new improved one. We now precompute the signal set passed to sigtimedwait, using an inverted set when necessary for compatibility with older kernels.
* The move to _retire() a thread in the GC instead of in the thread'smtm2003-06-293-21/+5
| | | | | | | exit function has invalidated the need for _spin[un]lock_pthread(). The _spin[un]lock() functions can now dereference curthread without the danger that the ldtentry containing the pointer to the thread has been cleared out from under them.
* Create compatibility links for libc_r on ia64 to prevent build-timemarcel2003-06-271-0/+12
| | | | | | | | | breakages. Note that runtime compatibility is not guaranteed. Future changes to setjmp/longjmp in libc will break threaded applications linked against libc_r.so.5 on ia64. We pull our "tier 2" card once more... Reviewed by: ru
* _thread_printf() is only used for debugging or in cases where something'smtm2003-06-091-2/+2
| | | | | screwed beyond all help, so it can just skip the pthreads wrapper for write(2) and call directly into it.
* Make C applications statically compiled with libthr work. Previously,mtm2003-06-041-0/+6
| | | | | | an application compiled -static with libthr would dump core in malloc(3) because the stub thread initialization routine in libc would be used instead of the libthr supplied one.
* Teach recent changes in the umtx structure in the kernel to the libthrmtm2003-06-031-1/+1
| | | | | | initialiazer. Found by: tinderbox
* Unwind the _giant_mutex from pthread_detach(). When detaching a joiner threadmtm2003-06-021-8/+8
| | | | | it's important the correct lock order is observed: lock first the joined and then the joiner.
* Consolidate static_init() and static_init_private into one function.mtm2003-06-021-17/+11
| | | | The behaviour of this function is controlled by the argument: private.
* .S comments must be C comments, not ASM ones.obrien2003-06-021-1/+1
|
* I botched one of my committs in the last round. Fix it.mtm2003-05-312-12/+11
|
* Make the mutex static initializers look more like the one formtm2003-05-291-25/+19
| | | | | | | | | condition variables. Cosmetic. Explicitly compare against PTHREAD_MUTEX_INITIALIZER. We shouldn't encourage calls to the mutex functions with null pointers to mutexes. Approved by: re/jhb
OpenPOWER on IntegriCloud