1. 19 Nov, 2019 1 commit
  2. 26 Jul, 2017 1 commit
  3. 24 Jul, 2017 1 commit
  4. 30 May, 2017 1 commit
  5. 21 Apr, 2016 2 commits
  6. 02 Jun, 2015 1 commit
  7. 09 Mar, 2015 1 commit
  8. 24 Sep, 2014 1 commit
  9. 23 Sep, 2014 1 commit
  10. 08 Aug, 2014 1 commit
  11. 06 Aug, 2014 1 commit
  12. 05 Aug, 2014 2 commits
    • Philippe Gerum's avatar
      alchemy: do not publish objects to clusters until they are fully built · 1f146d90
      Philippe Gerum authored
      We must NOT push Alchemy objects to clusters before they have been
      fully built, including the registration phase.
      Otherwise, a high priority task waiting on the binding service for the
      object to appear in a cluster might preempt the creation call
      immediately when the latter is updated, then destroy the half-baked
      resource being pushed, leading to invalid memory references and all
      sorts of unpleasant outcomes.
    • Philippe Gerum's avatar
      copperplate: work-around glibc race in cancel state handling · 75cc5dac
      Philippe Gerum authored
      This is a SMP race which seems to affect NPTL-based glibc releases
      (2.9 and 2.18 checked, other releases are likely concerned as
      well). The issue requires SMP setups to pop up, when
      --enable-async-cancel is mentioned on the Xenomai build configuration
      line. It was detected over the Mercury core, not checked on the Cobalt
      core. The work-around will fit both.
      The bug creates a situation where
      pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, ...) does not actually
      prevent subsequent asynchronous cancellation of the caller, in the
      following scenario:
      threadB has its cancellability set to PTHREAD_CANCEL_ENABLE,
      threadA[CPU0]: pthread_cancel(threadB)
      		(SIGCANCEL queued to threadB[CPU1])
      threadB[CPU1]: pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL)
      		(SIGCANCEL delivered to threadB[CPU1])
      			if (cancel_type(threadB) == PTHREAD_CANCEL_ASYNCHRONOUS)
      As illustrated, the source of this issue is in glibc's SIGCANCEL
      handler, which only (re-)checks the cancellability TYPE prior to
      entering the thread deletion process on the target CPU, omitting the
      cancellability STATE from this check. High concurrency may therefore
      cause the target CPU to receive an asynchronous cancellation signal
      out of sync, which contradicts the current cancellability state of the
      recipient thread, due to the delayed signal propagation induced by SMP
      Considering this, the cancellability state seems only safe for
      disabling the internal cancellation points, but can't be relied on for
      blocking asynchronous requests in SMP configurations.
      The work-around is to make sure to turn the cancellability type to
      PTHREAD_CANCEL_DEFERRED in addition to disabling cancellation with
      Copperplate, and all Copperplate-based APIs are affected by the
  13. 02 Aug, 2014 1 commit
  14. 30 Jul, 2014 1 commit
  15. 03 Jul, 2014 1 commit
  16. 25 Jun, 2014 1 commit
  17. 16 Jun, 2014 1 commit
  18. 12 Jun, 2014 1 commit
  19. 27 May, 2014 1 commit
  20. 26 May, 2014 1 commit
    • Philippe Gerum's avatar
      copperplate: substitute SCHED_RT with SCHED_FIFO · 0ee9288d
      Philippe Gerum authored
      Now that Cobalt supports up to 256 priority levels with the SCHED_FIFO
      class, we may assign all regular real-time threads directly to the
      SCHED_CORE is introduced as an alias to the scheduling class giving
      access to the highest priority levels assigned to internal server
  21. 21 May, 2014 1 commit
    • Philippe Gerum's avatar
      copperplate: introduce threadobj_set_schedparam() · ffdee1e9
      Philippe Gerum authored
      threadobj_set_priority() is replaced and superseded by
      threadobj_set_schedparam(), for changing the scheduling parameters of
      a thread. Unlike its predecessor, this new service does not decide of
      the target scheduling class (depending on the priority level), which
      is left to the caller instead.
      As a notable side-effect, threadobj_set_rr() is dropped, since
      enabling round-robin basically means switching to SCHED_RR via a call
      to threadobj_set_schedparam(), and disabling it happens implicitely
      whenever a thread leaves the SCHED_RR class.
  22. 20 May, 2014 1 commit
  23. 15 May, 2014 1 commit
    • Philippe Gerum's avatar
      copperplate: tag high-level blocking services with warn_unused_result · de9d8f3c
      Philippe Gerum authored
      The return value of any such service may restrict the valid execution
      flow for the caller, as a break condition may have been received, or
      the target object might have become stale while sleeping.
      Mark these calls with GCC's warn_unused_result attribute, to make sure
      these events won't go unnoticed in the client code.
  24. 14 May, 2014 1 commit
    • Philippe Gerum's avatar
      copperplate: systematically check basic IPC inits · edc7d53b
      Philippe Gerum authored
      As Cobalt might fail allocating resources for any basic IPC object
      (i.e. mutex, sem, condvar, event or monitor), we should check the
      return value of each of the related init call.
      Very nasty bugs might surface otherwise, haunting the code undetected
      until the core falls short of a critical runtime resource (e.g. heap
      memory shared between the Cobalt core and userland).
  25. 12 May, 2014 3 commits
    • Philippe Gerum's avatar
      copperplate/threadobj: introduce remote agent for thread operations · e0791de2
      Philippe Gerum authored
      In shared multi-processing mode, cancelling remote threads or updating
      their scheduling parameters require going through an agent thread,
      running on the process they belong to.
      This patch series introduces such mechanism, so that
      threadobj_cancel() and threadobj_set_priority() work transparently,
      regardless of whether or not the target thread runs in the current
      CAUTION: remote operations are implemented by a fully asynchronous
      protocol. The status returned to a caller for an operation affecting a
      remote thread, tells whether the request was successfully sent to the
      agent, but does not reflect the final operation status in the remote
      process. The remote agent will issue a warning message in case of
      failure to carry out an operation though.
    • Philippe Gerum's avatar
      alchemy/task: require local task for rt_task_slice() · 122492cd
      Philippe Gerum authored
      This follows the restriction imposed on the target scope for calling
    • Philippe Gerum's avatar
      alchemy/task: require local thread for rt_task_set_periodic() · 5da01c23
      Philippe Gerum authored
      We enforce process locality for target threads since Cobalt wants this
      for pthread_make_periodic_np(), although Mercury would accept remote
      This seems an acceptable limitation compared to introducing a new
      Cobalt API for supporting a somewhat weird feature (i.e. controlling
      periodic behavior of remote threads).
  26. 30 Apr, 2014 1 commit
    • Philippe Gerum's avatar
      alchemy: do not publish half-baked objects · bdfcfe58
      Philippe Gerum authored
      Object control blocks must be fully built and sane before indexed by
      their respective clusters. Otherwise, binding operations from remote
      threads may succeed too early, which open windows for referring to
      partly initialized objects, which would be quite unfortunate.
  27. 29 Apr, 2014 3 commits
  28. 21 Feb, 2014 1 commit
  29. 11 Feb, 2014 2 commits
    • Jan Kiszka's avatar
      alchemy: Replace static variable no_alchemy_task with macro · 6b64595e
      Jan Kiszka authored
      The current definition of a static const variable representing an
      invalid alchemy task is both C++-incompatible and may leave variables in
      the .bss of modules behind that are including task.h, even if they don't
      use the symbol. So replace it with a macro that builds the required
      struct on-the-fly.
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
    • Philippe Gerum's avatar
      copperplate/internal: add parent-child handshake protocol at spawn · 4febef95
      Philippe Gerum authored
      We want to provide the ability to run a prologue code on behalf of the
      emerging child context, which the parent shall wait for completion of
      before continuing.
      This feature can be used to guarantee that a child thread has
      performed a set of actions before the caller of
      copperplate_create_thread() is allowed to refer to it.
  30. 08 Feb, 2014 1 commit
  31. 28 Jan, 2014 1 commit
  32. 07 Jan, 2014 1 commit
  33. 23 Oct, 2013 1 commit