[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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: phil-list-admin redhat com [mailto:phil-list-admin redhat com] On Behalf Of Senthil Nathan V
Sent: Wednesday, December 17, 2003 22:04
To: phil-list redhat com
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 Phil-list redhat com 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.






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]