On 07/03/2014 04:56 PM, Michael Haberler wrote:
> we found this:
> http://stackoverflow.com/questions/9857760/can-an-arm-interrupt-occur-in-mid-instruction
> and are considering which impact that has on machinekit, which uses doubles
> in memory shared between threads, relying on updates being a
On 07/03/2014 10:11 AM, Kim De Mey wrote:
What I think that goes wrong is that the lock which is taken in
threadobj_notify_entry() is not released before threadobj_start()
continues at wait_on_barrier(thobj, __THREAD_S_ACTIVE).
Until threadobj_notify_entry() releases that lock, there is no way
we found this:
http://stackoverflow.com/questions/9857760/can-an-arm-interrupt-occur-in-mid-instruction
and are considering which impact that has on machinekit, which uses doubles in
memory shared between threads, relying on updates being atomic
I wonder if this topic has come up in the Xenomai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/03/2014 10:38 AM, Arnaud Degroote wrote:
> On 02/Jul - 19:59, Gilles Chanteperdrix wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>>
>> Well, this sucks, posted writes increase the timer programming
>> latency.
>>
>> Does the laten
On 07/03/2014 10:22 AM, Frede Florian wrote:
> Hello,
>
> We started a new real time project. For this project we decided to
> compare the PREEMPT_RT and Xenomai on our future hardware. For this we
> got two developer board from Phytec.
>
> * Linux-phyCORE-AM335x-Kit
>
> (https://www.osa
e: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL:
<http://www.xenomai.org/pipermail/xenomai/attachments/20140703/b947d875/attachment.sig>
___
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
Hello,
We started a new real time project. For this project we decided to
compare the PREEMPT_RT and Xenomai on our future hardware. For this we
got two developer board from Phytec.
* Linux-phyCORE-AM335x-Kit
(https://www.osadl.org/Profile-of-system-in-rack-7-slot-5.qa-profile-r7s5.0.htm
Hello,
I've encountered a deadlock in the finalize_thread() call in threadobj.c
I can easy reproduce the problem with a simple test case where I have
a psos task which in a loop creates, starts and deletes another psos
task.
The created tasks have a priority lower or equal to the priority of
the
