Hi Adam, Alexandre,
thank you very much for your help.
I know how CS works, it doesnt help to my requirement,
it has much more cost than my delay operation in details.
we have no problem with CPU load. it is almost %60 in idle.
The problem is on DISK I/O. especially if you have too much
table, relations, indexes.
in shortly bigger data, more than cachce resources.

Let me give you my scenario,
We are working for goverment hospitals.
As you can guess they are(our users) officer and work only in rush
ours.
Patients receptions, actions and lab devices communication shouldn't
go in a lag.
Invoice,statistical and managament related services not so much time-
critical. it is not important if their reports or browsings fast or
not so fast. Also they read nearly whole database to get a report.
You know FB works on DISC file.
At CPU level OS makes a good time sharing for proccess/threads,
so i thnk my spin counter doesn't effect other users so much.
I made a plan to spread DISC I/O requests in time, with some
conditions like, while ( not current_time between '08:00'
and '17:00' do spin..
You know select doesn't lock any recource in FB.
So that, non-time-critical users will get slow respons and understand
how heavy their task. At this time our FB works at maximum speed and
they like to play with data results.
That was all.
Writing a UDF to force the thread to sleep was best idea.
Sorry about my urgent solution and post.
Never be again.


Regards.

Ali

P.S. To Helen, i never post a new thread for any reply, it is a
yahoo's problem. I can understand you about my language,
it is not about only my english, i have problems to communicate
with my people too. thank you for your warning and URL referance,
i don't have time to read it, anyway i will not post any mail to
prevent problems about me.