summaryrefslogtreecommitdiff
path: root/libpthread/TODO
diff options
context:
space:
mode:
Diffstat (limited to 'libpthread/TODO')
-rw-r--r--libpthread/TODO177
1 files changed, 0 insertions, 177 deletions
diff --git a/libpthread/TODO b/libpthread/TODO
deleted file mode 100644
index d7e54da6..00000000
--- a/libpthread/TODO
+++ /dev/null
@@ -1,177 +0,0 @@
--*- Mode: outline -*-
-
-* Interfaces
-** All interfaces specified by IEEE Std 1003.1-2001 are present, however,
- pthread_kill and pthread_sigmask are defined in <pthread.h> and not
- <signal.h> as they should be. Once we are compiled with glibc,
- this should be eaiser.
-
-* Test cases. Can never have enough.
-
-* Ports
- Port to other kernels (e.g. Linux and FreeBSD) and test on other
- platforms.
-
-* Implementation details
-** pthread_atfork
- This cannot be implemented without either changing glibc to export
- some hooks (c.f. libc/sysdeps/mach/hurd/fork.c) or by providing a
- custom fork implementation that wraps the origial using dlopen et
- al.
-
-** Scheduling and priorities
-
- We do not support scheduling right now in any way what so ever.
-
- This affects:
- pthread_attr_getinheritsched
- pthread_attr_setinheritsched
- pthread_attr_getschedparam
- pthread_attr_setschedparam
- pthread_attr_getschedpolicy
- pthread_attr_setschedpolicy
- pthread_attr_getscope
- pthread_attr_setscope
-
- pthread_mutexattr_getprioceiling
- pthread_mutexattr_setprioceiling
- pthread_mutexattr_getprotocol
- pthread_mutexattr_setprotocol
- pthread_mutex_getprioceiling
- pthread_mutex_setprioceiling
-
- pthread_setschedprio
- pthread_getschedparam
- pthread_setschedparam
-
-** Alternate stacks
-
- Supporting alternate stacks (via pthread_attr_getstackaddr,
- pthread_attr_setstackaddr, pthread_attr_getstack,
- pthread_attr_setstack, pthread_attr_getstacksize and
- pthread_attr_setstacksize) is no problem as long as they are of the
- correct size and have the correct alignment. This is due to
- limitations in the Hurd TSD implementation
- (c.f. <hurd/threadvar.h>).
-
-** Cancelation
-*** Cancelation points
- The only cancelation points are pthread_join, pthread_cond_wait,
- pthead_cond_timedwait and pthread_testcancel. Need to explore if
- the hurd_sigstate->cancel_hook (c.f. <hurd/signal.h>) provides the
- desired semantics. If not, must either wrap the some functions
- using dlsym or wait until integration with glibc.
-*** Async cancelation
- We inject a new IP into the cancelled (running) thread and then
- run the cancelation handlers
- (c.f. sysdeps/mach/hurd/pt-docancel.c). The handlers need to have
- access to the stack as they may use local variables. I think that
- this method may leave the frame pointer in a corrupted state if
- the thread was in, for instance, the middle of a function call.
- The robustness needs to be confirmed.
-
-** Process Shared Attribute
-
- Currently, there is no real support for the process shared
- attribute. spinlocks work because we just use a test and set loop,
- however, barriers, conditions mutexes and rwlocks, however, signal
- wakeups via ports of which the names are process local.
-
- We could have some process local data that is hashed to via the
- address of the data structure. Then the first thread that blocks
- per process would spin on the shared memory area and all others
- would then block as normal. When the resource became available,
- the first thread would signal the other local threads as necessary.
- Alternatively, there could be some server, however, this opens a
- new question: what can we use as an authentication agent.
-
-** Locking algorithm
-
- When a thread blocks, it puts itself on a queue and then waits for
- a message on a thread local port. The thread which eventually does
- the wakeup sends a message to the waiter thereby waking it up. If
- the wakeup is a broadcast wakeup (e.g. pthread_cond_broadcast,
- pthread_barrier_wait and pthread_rdlock_unlock), the thread must
- send O(N) messages where N is the number of waiting threads. If
- all the threads instead received on a lock local (rather than
- thread local) port then the thread which eventually does the wake
- need just do one operation, mach_port_destroy and all of the
- waiting threads would wakeup and get MACH_RCV_PORT_DIED back from
- mach_msg. Note that the trade off is that the port must be
- recreated. This needs to be benchmarked.
-
- A possible problem with this is scheduling priorities. There may
- be a preference for certain threads to wakeup before others
- (especially if we are not doing a broadcast, for instance,
- pthread_mutex_unlock and pthread_cond_signal). If we take this
- approach, the kernel chooses which threads are awakened. If we
- find that the kernel makes the wrong choices, we can still overcome
- this by merging the two algorithms: have a list of ports sorted in
- priority order and the waker does a mach_port_destroy on each as
- appropriate.
-
-** Barriers
-
- Barriers can be very slow and the contention can be very high. The
- above algorithm is very appealing, however, this may be augmented
- with an initial number of spins and yields. It is expected that
- all of the threads reach the barrier within close succession, thus
- queuing a message may be more expensive. This needs to be
- benchmarked.
-
-** Clocks
-*** pthread_condattr_setclock allows a process to specify a clock for
- use with pthread_cond_timedwaits. What is the correct default for
- this, right now, we use CLOCK_REALTIME, however, we are really
- using the system clock which, if I understand correctly, is
- completely different.
-*** Could we even use other clocks? mach_msg uses a relative time against
- the system clock.
-*** pthread_getcpuclockid just returns CLOCK_THREAD_CPUTIME_ID if defined.
- Is this the correct behavior?
-
-** Timed Blocking
-*** pthread_cond_timedwait, pthead_mutex_timedlock, pthread_rwlock_timedrdlock
- and pthread_rwlock_timedwrlock all take absolute times. We need
- to convert them to relative times for mach_msg. Is there a way
- around this? How will clock skew affect us?
-
-** weak aliases
- Use them consistently and correctly and start by reading
- http://sources.redhat.com/ml/libc-alpha/2002-08/msg00278.html.
-
-** TLS
- Support for TLS is only implemented for Mach/Hurd (x86).
-
-* L4 Specific Issues
-** Stack
-*** Size
- The stack size is defined to be a single page in
- sysdeps/l4/hurd/pt-sysdep.h. Once we are able to setup regions,
- this can be expanded to two megs as suggested by the Mach version.
- Until then, however, we need to allocate too much physical memory.
-*** Deallocation
- __thread_stack_dealloc currently does not deallocate the stack.
- For a proper implementation, we need a working memory manager.
-
-** Scheduling
-*** yield
- [L4] We cannot use yield for spin locks as L4 only yields to threads of
- priority which are greater than or equal to the yielding thread.
- If there are threads of lower priority, they are not considered;
- the yielding thread is just placed back on the processor. This
- introduces priority inversion quite quickly. L4 will not add a
- priority suppression function call. As such, we need to do
- an ipc with a small time out and then use exponential back off to
- do the actual waiting. This sucks.
-
-** Stub code
- [L4] We include <task_client.h> in pt-start.c, however, we need a library
- so we do not have to play with the corba stuff.
-
-** Root server and Task server
-*** Getting the tids.
- pt-start.c has a wonderfully evil hack that will never work well.
-
-** Paging
- We set the pager to the root server. Evil. Fix this in pt-start.c.