Split up the potential thread priority change in the scheduler
release/cancel job operation. Protect the rate monotonic period state
with a dedicated SMP lock. This avoids a race condition during
_Rate_monotonic_Timeout() while _Rate_monotonic_Cancel() is called on
another processor.
It is possible that the owner of the terminal link of a thread queue
path waits on a thread queue. However, this thread queue has no owner,
e.g. a thread queue of a message queue.
There was a subtile race condition in _Thread_queue_Do_extract_locked().
It must first update the thread wait flags and then restore the default
thread wait state. In the previous implementation this could lead under
rare timing conditions to an ineffective _Thread_Wait_tranquilize()
resulting to a corrupt system state.
Update #2556.
The newly created macro adds any kind of variable into a linker set. It
allows (for example) the saving an execution state of a function using
the following method:
- put a group of different variables into one linker set
- save the memory area containing the group of variables before the
execution of a function
- restore the memory area after the function has been executed
Code works but there is problem how to setup caching for the regions
(arm_cp15_set_translation_table_entries arguments).
If ARMV7_MMU_DATA_READ_WRITE_CACHED is used then CPU
accesses are noncoherent with VideoCore and some
part of image update are not visible until pushed from
cache by other activities. If ARMV7_MMU_DATA_READ_WRITE
is used then access is extremely slow.
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
The first, mistake in buffer size computation for cache flush
and invalidate has been corrected.
GCC __attribute__( ( aligned( 64 ) ) ) should work and works for local
variables. Code ensures right stack alignment. But attribute has
to be moved to type declaration to ensure that structure size is affected
by attribute. But even this seems to not work reliably for some reason.
May it be, the stack area between frame start and end of local variable buffer
accessed during context switch or some stack prefetch during resturn
such way that some cache lines belonging to buffer are filled to cache.
Extending buffer by one more cache line padding helps there.
In the longer term perspective, buffer should be moved to some static
area or cache aligned dynamic memory allocated. Concurrent calls
to the VideoCore operations and access serialization should be added
too but problem is that some calls are required during workspace and MMU
setup so variant without need of mutex would be required as well.
Framebuffer setup code and other VideoCore calls check more
precisely for errors and do not proceed forward with incorrect
data now.
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
The mutex objects use the owner field of the thread queues for the mutex
owner. Use this and add a deadlock detection to
_Thread_queue_Enqueue_critical() for thread queues with an owner.
Update #2412.
Update #2556.
Close#2765.
The _Thread_Lock_acquire() function had a potentially infinite run-time
due to the lack of fairness at atomic operations level.
Update #2412.
Update #2556.
Update #2765.
Move the priority change due to priority interitance to the thread queue
enqueue operation to simplify the locking on SMP configurations.
Update #2412.
Update #2556.
Update #2765.
Raise the priority under thread queue lock protection and omit the
superfluous thread queue priority change, since the thread is extracted
anyway. The unblock operation will pick up the new priority.
Update #2412.
Update #2556.
Update #2765.
* Fixes a bug with elapsed time calculations misusing absolute time
arguments in nanosleep_helper by passing the requested relative interval.
* Fixes a bug with truncation of absolute timeouts by passing the
full 64-bit value to Thread_queue_Enqueue.
* Share yield logic between nanosleep and clock_nanosleep.
updates #2732
Sleeping with CLOCK_REALTIME should use the WATCHDOG_ABSOLUTE
clock discipline for the threadq so that the timeout interval
may change in case the clock source changes. Similarly,
CLOCK_MONOTONIC uses the WATCHDOG_RELATIVE threadq that will
only wakeup the thread after the requested count of ticks elapse.
updates #2732
Clock disciplines may be WATCHDOG_RELATIVE, WATCHDOG_ABSOLUTE,
or WATCHDOG_NO_TIMEOUT. A discipline of WATCHDOG_RELATIVE with
a timeout of WATCHDOG_NO_TIMEOUT is equivalent to a discipline
of WATCHDOG_NO_TIMEOUT.
updates #2732
