Re: blocking pre-emting

Hong Zhang wrote:

>you can not get the correct time in the first place.
>
>t
>=
>gettime();
>
>The assignment itself can be preempted for long time.
>The only guarantteed solution is to use atomic instruction to
>update kernel time variable if such thing exists.
>
>Hong
>
>>-----Original Message-----
>>From: [email protected] 
>>[mailto:[email protected]] On Behalf Of Senthil Nathan V
>>Sent: Wednesday, December 17, 2003 22:04
>>To: [email protected]
>>Subject: blocking pre-emting
>>
>>
>>  Hell Everyone!!
>>
>>   I have this situation. I need to take the current time of 
>>the system, and
>>update with the new value and set the time. I'm doing some 
>>thing like this
>>
>>1. t = gettime() ;
>>2. t = t + deviation ;
>>3. settime( t )  ;
>>
>> I assume that time taken to execute these statements is negligible. 
>>
>>My doubt is if there is no switch over at the time of 
>>execution of these 
>>statements the time would be set almost right but, if any switch over 
>>occurs before statement  3 and after statement  1. I might miss some 
>>seconds in the actual time. 
>>
>>
>>1. How do I over come this? 
>>2. Is there any way I to block pre-emtion at the time of 
>>execution of these 
>>sequence of statements in user program?
>>
>> Thanks in advance..
>>
>> --regards,
>>   Senthil Nathan V
>>   Odyssey Technologies Limited
>>  
>>  
>>
>>
>>-- 
>>Phil-list mailing list
>>[email protected]
>>https://www.redhat.com/mailman/listinfo/phil-list
>>
>
>
Assuming support of POSIX real-time scheduling priority levels, a thread 
can block preemption by other user-space processes by temporarily 
boosting its priority to the maximum level allowed for FIFO scheduling. 
The 'atomic' operations are then performed at the boosted priority level 
and the (saved) initial thread priority is restored after the 'atomic' 
operations have been completed. This of course does not prevent 
preemption by ISRs, but normally those (if well written) will produce 
negligible delays. This strategy worked with the old 'linuxthreads' 
library and kernels up through 2.4.18, but as yet I haven't had an 
opportunuity to experiment with the 2.6 kernel and nptl.

Gary Robertson,
Cybertech Systems, Inc.