RE: await asleep
The functions await() and asleep() in kern_synch.c
are marked as EXPERIMENTAL/UNTESTED.
Is this comment still valid? Does anyone have used
those functions successfully? Should I better not
use them in my device driver code for RELENG_4?
How do I correctly cancel a request (as I should do
according to the man page): asleep (NULL, 0, NULL, 0)?
The await family was removed in 5.x and beyond, so trying to
use them in 4.x will make your driver very unportable. There
are better ways than await to handle delayed events.
Ok, my [classical] situation is this:
1. an interrupt handler writes into a queue
2. a read function reading from the queue
pseudo code using asleep()/await() (no error handling):
read()
{
forever {
while ! empty_queue() {
uiomove(uio, ...);
if (uio-uio_resid == 0) {
return 0;
}
}
asleep( read_queue, ...);
if (empty_queue ()) {
error = await (...);
} else {
asleep (NULL, ...);
}
}
}
If I want to do that with plain tsleep() I
have to use spl??() to lock the empty_queue() call
and not lose a wakeup() from the interrupt handler.
But if I add error checks the code becomes very ugly
compared to the solution above.
I never wrote a driver under 5.X. As I understand
I would use a mutex to access the queue and call msleep()
to sleep with the mutex unlocked. (That seems to simulate
pthread_cond_timedwait(), doesn't it?)
pseudo code:
read()
{
forever {
while ! empty_queue() {
uiomove(uio, ...);
if (uio-uio_resid == 0) {
return 0;
}
}
mtx_lock (mutex);
if (empty_queue ()) {
error = msleep (queue, mutex, ...);
};
mtx_unlock (mutex);
}
}
How would you suggest to do that under 4.X
in an _elegant_ way w/o asleep/await?
Norbert
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: await asleep
On Wed, 27 Jul 2005, Norbert Koch wrote: The functions await() and asleep() in kern_synch.c are marked as EXPERIMENTAL/UNTESTED. Is this comment still valid? Does anyone have used those functions successfully? Should I better not use them in my device driver code for RELENG_4? How do I correctly cancel a request (as I should do according to the man page): asleep (NULL, 0, NULL, 0)? The await family was removed in 5.x and beyond, so trying to use them in 4.x will make your driver very unportable. There are better ways than await to handle delayed events. Well, there's tsleep() and wakeup() for FreeBSD 5.0. Other than that, what else can you do? These functions are deprecated in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should really use those instead of tsleep() and wakeup(). It seems the kernel in -current is still using tsleep() and wakeup() in some places. I thought we got rid of all these... -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: await asleep
Daniel Eischen wrote: On Wed, 27 Jul 2005, Norbert Koch wrote: The functions await() and asleep() in kern_synch.c are marked as EXPERIMENTAL/UNTESTED. Is this comment still valid? Does anyone have used those functions successfully? Should I better not use them in my device driver code for RELENG_4? How do I correctly cancel a request (as I should do according to the man page): asleep (NULL, 0, NULL, 0)? The await family was removed in 5.x and beyond, so trying to use them in 4.x will make your driver very unportable. There are better ways than await to handle delayed events. Well, there's tsleep() and wakeup() for FreeBSD 5.0. Other than that, what else can you do? These functions are deprecated in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should really use those instead of tsleep() and wakeup(). It seems the kernel in -current is still using tsleep() and wakeup() in some places. I thought we got rid of all these... Can you explain why tsleep and wakeup should no longer be used? I wasn't aware that they were formally deprecated. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: await asleep
On Wed, 27 Jul 2005, Scott Long wrote: Daniel Eischen wrote: On Wed, 27 Jul 2005, Norbert Koch wrote: The functions await() and asleep() in kern_synch.c are marked as EXPERIMENTAL/UNTESTED. Is this comment still valid? Does anyone have used those functions successfully? Should I better not use them in my device driver code for RELENG_4? How do I correctly cancel a request (as I should do according to the man page): asleep (NULL, 0, NULL, 0)? The await family was removed in 5.x and beyond, so trying to use them in 4.x will make your driver very unportable. There are better ways than await to handle delayed events. Well, there's tsleep() and wakeup() for FreeBSD 5.0. Other than that, what else can you do? These functions are deprecated in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should really use those instead of tsleep() and wakeup(). It seems the kernel in -current is still using tsleep() and wakeup() in some places. I thought we got rid of all these... Can you explain why tsleep and wakeup should no longer be used? I wasn't aware that they were formally deprecated. My mistake then. I thought they were deprecated when mutex and CVs were introduced. There is no need for them except for compatability, and the priority argument of tsleep() doesn't have any meaning any longer, right? -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: await asleep
Daniel Eischen wrote: On Wed, 27 Jul 2005, Scott Long wrote: Daniel Eischen wrote: On Wed, 27 Jul 2005, Norbert Koch wrote: The functions await() and asleep() in kern_synch.c are marked as EXPERIMENTAL/UNTESTED. Is this comment still valid? Does anyone have used those functions successfully? Should I better not use them in my device driver code for RELENG_4? How do I correctly cancel a request (as I should do according to the man page): asleep (NULL, 0, NULL, 0)? The await family was removed in 5.x and beyond, so trying to use them in 4.x will make your driver very unportable. There are better ways than await to handle delayed events. Well, there's tsleep() and wakeup() for FreeBSD 5.0. Other than that, what else can you do? These functions are deprecated in 5.x and 6.x in favor of condvar(9) and mutex(9), so you should really use those instead of tsleep() and wakeup(). It seems the kernel in -current is still using tsleep() and wakeup() in some places. I thought we got rid of all these... Can you explain why tsleep and wakeup should no longer be used? I wasn't aware that they were formally deprecated. My mistake then. I thought they were deprecated when mutex and CVs were introduced. There is no need for them except for compatability, Incorrect. A mutex is not a replacement for sleep. CV's and semaphores implement some of what tsleep does, but tsleep is absolutely appropriate when you want to sleep for an event (like disk i/o completing) and don't need to worry about mutexes. Not every inch of the kernel needs to be covered by mutexes, Giant or otherwise. and the priority argument of tsleep() doesn't have any meaning any longer, right? I thought it did, but John can give the definitive answer. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: await asleep
On Wed, 27 Jul 2005, Scott Long wrote: Daniel Eischen wrote: My mistake then. I thought they were deprecated when mutex and CVs were introduced. There is no need for them except for compatability, Incorrect. A mutex is not a replacement for sleep. CV's and semaphores implement some of what tsleep does, but tsleep is absolutely appropriate when you want to sleep for an event (like disk i/o completing) and don't need to worry about mutexes. Not every inch of the kernel needs to be covered by mutexes, Giant or otherwise. Traditionally, you did splXXX() then tsleep(). But splXXX() has been deprecated and you need to use mutexes for protection. If you are going to sleep for an event, that is cv_wait() and friends and you use the mutex for protection. It's hard to imagine that queueing disk I/O requests and their completions don't need mutexes (or lockmgr?) for protection, but I'll take your word for it. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: await asleep
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : and the priority argument of tsleep() doesn't have any meaning : any longer, right? : : : I thought it did, but John can give the definitive answer. Priority is still useful. It is the same priority that msleep uses. tsleep is completely equivalent to msleep with a null mtx parameter. The priority field is indeed used: /* * Adjust this thread's priority. */ mtx_lock_spin(sched_lock); sched_prio(td, priority PRIMASK); mtx_unlock_spin(sched_lock); msleep is a different primitive that cv_wait and friends. cv_wait enforces good mutex practices and generally should be used... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
await asleep
Hello. The functions await() and asleep() in kern_synch.c are marked as EXPERIMENTAL/UNTESTED. Is this comment still valid? Does anyone have used those functions successfully? Should I better not use them in my device driver code for RELENG_4? How do I correctly cancel a request (as I should do according to the man page): asleep (NULL, 0, NULL, 0)? Any help appreciated. Norbert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: await asleep
Norbert Koch wrote: Hello. The functions await() and asleep() in kern_synch.c are marked as EXPERIMENTAL/UNTESTED. Is this comment still valid? Does anyone have used those functions successfully? Should I better not use them in my device driver code for RELENG_4? How do I correctly cancel a request (as I should do according to the man page): asleep (NULL, 0, NULL, 0)? Any help appreciated. Norbert The await family was removed in 5.x and beyond, so trying to use them in 4.x will make your driver very unportable. There are better ways than await to handle delayed events. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
