> So, what is the result? Did you find the bug?
Yes, I think so. 
The problem was in my rewriting of JamVM. I have implemented Java 
PeriodicEventHandlers using periodic RT_TASKs, and re-implemented Java object 
allocation with synchronized methods, using RT_MUTEX to utilize the priority 
inheritance included in Xenomai. Each handler has a private native memoryArea 
(no Garbage Collector because of real-time constraints).
The allocation of a new object and calling its synchronized method now gives 
the output:

=> Native: enterNativeMemArea

[alloc.c]: rt_mutex_create err: 0; 
[alloc.c]: ob->rt_lock.opaque: 75; 

[lock.c]: ob->rt_lock.opaque: 75; 
[lock.c]: rt_mutex_acquire, result 0;

[lock.c]: ob->rt_lock.opaque: 75;
[lock.c]: rt_mutex_release, result 0; 

[alloc.c]: rt_mutex_delete, err: 0; 
[alloc.c]: ob->rt_lock.opaque: 75; 

=> Native: resetMemArea: after-before=used: 10232 - 10208 = 24 Bytes;

This should be OK.
I have (still) problems, if I use System.out.println in the synchronized 
method, but now I know it is because of my insufficient re-implementation of 
JamVM.
Vh/Regards
Hans Sø

-----Original Message-----
From: Gilles Chanteperdrix [mailto:[email protected]] 
Sent: 22. august 2009 12:02
To: Hans Søndergaard (HSO)
Cc: [email protected]
Subject: Re: [Xenomai-help] rt_mutex_acquire returns -3

Hans Søndergaard (HSO) wrote:
> Thank you to both Gilles and Philippe.
> I followed the advises from you both:
> typedef struct object {
>   RT_MUTEX rt_lock; 
>    .. 
>  } Object;
> 
> and used:
>   printf("%ld", ob->rt_lock.opaque);
> to see output.

So, what is the result? Did you find the bug?

-- 
                                            Gilles.

_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help

Reply via email to