Commit Graph

7 Commits

Author SHA1 Message Date
Christian Helmuth ff5175ec76 libc: synchronization primitives based on monitor
The libc monitor facility enables the execution of monitor jobs by the
main thread when the monitor pool was charged. In comparison to the
current suspend/resume_all mechanism the main thread iterates over all
job functions in contrast to waking up all threads to check their
conditions by themselves. Threads are only woken up if the completion
condition was met.

This commit is the result of a collaboration with Christian Prochaska.
Many thanks for your support, Christian.

Fixes #3550
2020-02-10 14:21:47 +01:00
Christian Prochaska 07a40d028a libc: fix and cleanup pthread mutexes
Issue #3503
Fixes #3504
2019-11-19 14:23:57 +01:00
Norman Feske 648bcd1505 libc: unify use of namespaces
This patch unifies the patterns of using the 'Genode' and 'Libc'
namespaces.

Types defined in the 'internal/' headers reside in the 'Libc'
namespace. The code in the headers does not need to use the
'Libc::' prefix.

Compilation units import the 'Libc' namespace after the definition of
local types. Local types reside in the 'Libc' namespace (and should
eventually move to an 'internal/' header).

Since the 'Libc' namespace imports the 'Genode' namespace, there is
no need to use the 'Genode::' prefix. Consequently, code in the
compilation units rarely need to qualify the 'Genode' or 'Libc'
namespaces.

There are a few cases where the 'Libc', the 'Genode', and the global
(libc) namespaces are ambigious. In these cases, an explicit
clarification is needed:

- 'Genode::Allocator' differs from 'Libc::Allocator'.
- 'Genode::Env' differs from 'Libc::Env'.
- Genode's string functions (strcmp, memcpy, strcpy) conflict
  with the names of the (global) libc functions.
- There exist both 'Genode::uint64_t' and the libc'c 'uint64_t'.

Issue #3497
2019-11-19 14:10:55 +01:00
Norman Feske bf92232698 libc: split task.cc into multiple files
This patch is the first step of re-organizing the internal structure of
the libc. The original version involved many direct calls of global
functions (often with side effects) across compilation units, which
made the control flow (e.g., the initialization sequence) hard to
follow.

The new version replaces those ad-hoc interactions with dedicated
interfaces (like suspend.h, resume.h, select.h, current_time.h). The
underlying facilities are provided by the central Libc::Kernel and
selectively propagated to the various compilation units. The latter is
done by a sequence of 'init_*' calls, which eventually will be replaced
by constructor calls.

The addition of new headers increases the chance for name clashes with
existing (public) headers. To disambiguate libc-internal header files
from public headers, this patch moves the former into a new 'internal/'
subdirectory. This makes the include directives easier to follow and the
libc's source-tree structure more tidy.

There are still a few legacies left, which cannot easily be removed
right now (e.g., because noux relies on them). However, the patch moves
those bad apples to legacy.h and legacy.cc, which highlights the
deprecation of those functions.

Issue #3497
2019-11-19 14:10:55 +01:00
Norman Feske 0aedabd245 libc: remove global constructors
- readv_writev: move 'rw_lock' instance into a function scope,
  constructing the instance on the first access.
- select: move 'select_cb_list' instance into function scope.
- thread: move 'key_list_lock' and 'keys' into function scope.
- rwlock, semaphore, socket_fs_plugin, thread, thread_create:
  instantiate 'Libc::Allocator' per use, alleviating the need for a
  global instance.

Issue #3496
2019-09-20 14:16:01 +02:00
Christian Helmuth 6c42bd4dd3 libc: use non-anonymous 'operator new' and destroy()
This removes implementations of and also references to anonymous new and
delete operators from the libc implementation. As allocators for
new/delete Libc::Allocator instances are used, which (paradoxically) map
to libc malloc/free.
2019-05-27 14:52:53 +02:00
Ehmry - 7a11384177 Merge pthread into libc library
The pthread API is considered a standard feature of libc so better to
simply merge it with the libc. Pthreads are in fact already a part of
the libc in the form of weak symbols. This merger is also a prerequisite
for better integrating pthreads with the libc I/O task.

Fix #3054
2018-11-29 11:46:01 +01:00