1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247
|
/*!\file mutex.c
* \brief Nanokernel mutex services.
* \author Philippe Gerum
*
* Copyright (C) 2001,2002,2003 Philippe Gerum <rpm@xenomai.org>.
*
* Xenomai is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* Xenomai is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with Xenomai; if not, write to the Free Software Foundation,
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* As a special exception, the RTAI project gives permission
* for additional uses of the text contained in its release of
* Xenomai.
*
* The exception is that, if you link the Xenomai libraries with other
* files to produce an executable, this does not by itself cause the
* resulting executable to be covered by the GNU General Public License.
* Your use of that executable is in no way restricted on account of
* linking the Xenomai libraries code into it.
*
* This exception does not however invalidate any other reasons why
* the executable file might be covered by the GNU General Public
* License.
*
* This exception applies only to the code released by the
* RTAI project under the name Xenomai. If you copy code from other
* RTAI project releases into a copy of Xenomai, as the General Public
* License permits, the exception does not apply to the code that you
* add in this way. To avoid misleading anyone as to the status of
* such modified files, you must delete this exception notice from
* them.
*
* If you write modifications of your own for Xenomai, it is your
* choice whether to permit this exception to apply to your
* modifications. If you do not wish that, delete this exception
* notice.
*
* \ingroup mutex
*/
/*!
* \ingroup xenomai
* \defgroup mutex Nanokernel mutex services.
*
* Nanokernel mutex services.
*
********************************************************************
* [WARNING] Mutex services are deprecated in newer versions of the
* Xenomai nucleus, basically due to design and performance issues. Do
* not use this facility if you plan to port to RTAI/fusion.
********************************************************************
*
* Mutexes are internal synchronization objects that do NOT rely on
* the standard nanokernel scheduling routines to operate. However,
* they share the same protocol inheritance scheme with the regular
* xnsynch objects for the sake of clarity and efficiency. In other
* words, code in mutex.c and synch.c cooperate on the same logic and
* data structures for handling PIP both for kernel mutexes and
* regular resources.
*
* One should keep in mind that a thread claiming a mutex is NOT
* actually suspended, but the current mutex owner is simply
* rescheduled before the "sleeper" instead. Priority inheritance
* allows to boost the current mutex owner so that it can release the
* lock as soon as possible.
*
* Consequently, blocking or suspending a thread that holds a mutex is
* a BUG! However, the nanokernel provides for a special mechanism
* that releases a given interface mutex atomically when
* xnpod_suspend_thread() is called for the current thread,
* reacquiring it on return of this routine. This mechanism should be
* understood as a lock-breaking preemption point atomically performed
* just before the current thread is switched out.
* @see xnpod_schedule() for more on this.
*
*@{*/
#include <stdarg.h>
#include "rtai_config.h"
#include "xenomai/pod.h"
#include "xenomai/mutex.h"
#include "xenomai/module.h"
/*
* Mutexes are internal synchronization objects that do NOT rely on
* the standard nanokernel scheduling routines to operate. However,
* they share the same protocol inheritance scheme with the regular
* xnsynch objects for the sake of clarity and efficiency. In other
* words, code in mutex.c and synch.c cooperate on the same logic and
* data structures for handling PIP both for kernel mutexes and
* regular resources.
*
* One should keep in mind that a thread claiming a mutex is NOT
* actually suspended, but the current mutex owner is simply
* rescheduled before the "sleeper" instead. Priority inheritance
* allows to boost the current mutex owner so that it can release the
* lock as soon as possible.
*
* Consequently, blocking or suspending a thread that holds a mutex is
* a BUG! However, the nanokernel provides for a special mechanism
* that releases a given interface mutex atomically when
* xnpod_suspend_thread() is called for the current thread,
* reacquiring it on return of this routine. This mechanism should be
* understood as a lock-breaking preemption point atomically performed
* just before the current thread is switched out. See
* xnpod_schedule() for more on this.
*/
void xnmutex_init (xnmutex_t *mutex)
{
xnsynch_init(&mutex->synchbase,XNSYNCH_PRIO|XNSYNCH_PIP);
xnsynch_set_flags(&mutex->synchbase,XNSYNCH_KMUTEX);
xnarch_atomic_set(&mutex->lockcnt,1);
}
void xnmutex_sleepon_inner (xnmutex_t *mutex, xnthread_t *sleeper)
{
xnthread_t *owner = xnsynch_owner(&mutex->synchbase);
if (xnsynch_nsleepers(&mutex->synchbase) > 0)
/* lockcnt was negative and decremented on entry -- Ensure
that all sleepers count for a single decrementation. */
xnarch_atomic_inc(&mutex->lockcnt);
#ifdef CONFIG_RTAI_XENOMAI_DEBUG
if (!testbits(owner->status,XNREADY))
xnpod_fatal("owner (name=%s, status=0x%lx) of mutex %p is not runnable -- cannot boost",
owner->name,
owner->status,
mutex);
if (xnpod_priocompare(sleeper->cprio,owner->cprio) < 0)
xnpod_fatal("badly ordered readyq?!");
#endif /* CONFIG_RTAI_XENOMAI_DEBUG */
insertpqf(xnsynch_wait_queue(&mutex->synchbase),
&sleeper->plink,
sleeper->cprio);
setbits(sleeper->status,XNWMUTEX);
/* Now we have to fiddle with the priority inheritance, taking in
account that the mutex owner might already undergo a priority
boost from a synchronization object it owns. In any cases, the
main idea is: "always raise the mutex owner priority, don't
lower it until it releases the mutex, ever." */
if (xnpod_priocompare(sleeper->cprio,owner->cprio) > 0)
{
/* Raise the owner's priority to solve the current priority
inversion. Basically, this is a simplified version of
xnsynch_sleep_on(). */
if (!testbits(owner->status,XNBOOST))
{
owner->bprio = owner->cprio;
setbits(owner->status,XNBOOST);
}
if (!xnsynch_test_flags(&mutex->synchbase,XNSYNCH_CLAIMED))
{
insertpqf(&owner->claimq,
&mutex->synchbase.link,
getheadpq(xnsynch_wait_queue(&mutex->synchbase))->prio);
xnsynch_set_flags(&mutex->synchbase,XNSYNCH_CLAIMED);
}
owner->cprio = sleeper->cprio;
}
xnpod_schedule_runnable(owner,XNPOD_SCHEDLIFO);
}
void xnmutex_wakeup_inner (xnmutex_t *mutex, int flags)
{
xnthread_t *owner = xnsynch_owner(&mutex->synchbase), *sleeper;
spl_t s;
splhigh(s);
/* Pick the highest priority sleeper. */
sleeper = link2thread(getpq(xnsynch_wait_queue(&mutex->synchbase)),plink);
clrbits(sleeper->status,XNWMUTEX);
if (xnsynch_test_flags(&mutex->synchbase,XNSYNCH_CLAIMED))
{
removepq(&owner->claimq,&mutex->synchbase.link);
xnsynch_clear_flags(&mutex->synchbase,XNSYNCH_CLAIMED);
}
if (xnsynch_nsleepers(&mutex->synchbase) > 0)
/* lockcnt was zero on entry -- Ensure that the next unlock
will beget a wakeup if sleepers remain. */
xnarch_atomic_dec(&mutex->lockcnt);
if (testbits(owner->status,XNBOOST))
{
int downprio = owner->bprio;
if (countpq(&owner->claimq) == 0)
clrbits(owner->status,XNBOOST);
else
{
/* Find the highest priority needed to enforce the PIP. */
int rprio = getheadpq(&owner->claimq)->prio;
if (xnpod_priocompare(rprio,downprio) > 0)
downprio = rprio;
}
owner->cprio = downprio;
if (owner->wchan)
/* Ignoring the XNDREORD flag on purpose here. */
xnsynch_renice_sleeper(owner);
}
#ifdef CONFIG_RTAI_XENOMAI_DEBUG
if (sleeper->sched->runthread != owner)
xnpod_fatal("mutex %p not released by owner\n",mutex);
#endif /* CONFIG_RTAI_XENOMAI_DEBUG */
xnsynch_set_owner(&mutex->synchbase,sleeper);
xnpod_schedule_runnable(sleeper,XNPOD_SCHEDLIFO|flags);
splexit(s);
}
/*@{*/
EXPORT_SYMBOL(xnmutex_init);
EXPORT_SYMBOL(xnmutex_sleepon_inner);
EXPORT_SYMBOL(xnmutex_wakeup_inner);
|