Mr. Hofrat,
> > > Will rtl_no_interrupts(), rtl_restore_interrupts() help
> > > me in achieving this atomicity. But if a high priority
> > > thread is kicked will the scheduler schedule this high
> > > priority thread immediately ?
> >
> > As far as I know, if interrupts are disabled, the thread
> can't be kicked.
> > Nothing can happen but the execution of the current code.
> >
> nop - rt-signals are not disabled by rtl_no_interrupts :
Ummmm... Yes they are. If you have run rtl_no_interrupts, you have
to either a) specifically re-enable the interrupts with a
rtl_restore_interrupts or b) cause the scheduler to run (which will restore
another processes flags register thus setting the interrupt status to
whatever that process had - presumably enabled). Normal scheduling will not
happen within a process which has used the rtl_no_interrupts /
rtl_resotre_interrupts pair.
> thread A (non periodic):
>
> while(1){
> rtl_no_interrupts(flags);
> pthread_suspend_np(pthread_selfe());
> ...wait for signal from other rt-thread...
> do_something();
> rtl_restore_interrtups(flags);
> }
>
> thread B (periodic thread):
>
> pthread_make_periodic_np(....)
>
> while(1){
> pthread_wait_np();
> pthread_kill(threadA,RTL_SIGNAL_WAKEUP);
> }
>
> then hardware interrupts will be disabled for the critical
> section in thread
> A but the periodic thread B will still wake it up.
But only because of the pthread_suspend_np in the first thread which
forces a call to the scheduler (which restores the flags register from the
highest priority computable process which, presumably, has interrupts
enabled). If another higher priority periodic thread was scheduled to
execute when thread A is executing do_something() it will, in fact, not run
until A gets back around to the pthread_suspend_np.
In fact it is not obvious to me why this thread even has the
rtl_no_interrupts/rtl_restore_interrupts in the loop. Simply executing the
rtl_no_interrupts before the while(1) would have the desired effect and get
rid of some push/cli/pop cruft.
This is a very specific case where thread A is allowing
multi-tasking by dint of its call to pthread_suspend_np. You are correct
that periodic thread B will wake up A. The problem with this sort of
technique is that the responsibility for making sure all deadlines are met
now rests firmly, and completely, on the shoulders of the programmer.
Others may disagree but I hold as self-evident that
rtl_no_interrupts/rtl_restore_interrupts should only be used for very short
sections of code when bad things would happen if interrupted. An excellent
example of this is updating the buffer pointers on serial port handling
code.
Regards,
Steve Cohen
--------------------------
Stephen D. Cohen
Engineering Manager
Xybion Sensor Positioning Systems
11528 53rd Street North
Clearwater, FL 33760
Voice: (727) 299-0150
Fax: (727) 299-0804
[EMAIL PROTECTED]
www.xybion.com
***********************************************************************
This email, and any attachments, contains confidential and privileged information
intended for the use of the addressee. If you are not the intended recipient or an
authorized representative of the recipient, do not read or distribute the contents of
this email and delete it from your system. This email and all attachments have been
scanned for viruses and are believed to be virus free. However, it is the recipient's
responsibility to ensure that they are virus free. Xybion does not accept any
responsibility for any loss or damage arising in any way from use of this email and
attachments. Xybion also does not accept responsibility for personal email or email
not associated with its business purposes.
***********************************************************************
_______________________________________________
Rtl mailing list
[EMAIL PROTECTED]
http://www2.fsmlabs.com/mailman/listinfo.cgi/rtl
