> lis_lockqf() will only return an error if `q' has qlock syncrhonization
> specified (the function merely returns zero if q->q_qsp is NULL). This
> feature was not even present in 2.16.18, so I'm a little confused by the
> comparison.
> specified (the function merely returns zero if q->q_qsp is NULL). This
> feature was not even present in 2.16.18, so I'm a little confused by the
> comparison.
I'm probably missing something.
My understanding was:
1. The lis_qlockf() function exists in both 2.16.18 and 2.18.0.
2. In _both_ releases it serves exactly the same purposes, like protecting
queue when, say, put function executed.
2a. In _both_ releases it is called in pretty much the same LiS places,
like in lis_safe_do_putmsg() it protects queue while
(*(q->q_qinfo->qi_putp))(q, mp); is executed.
3. The difference is in implementation of locking functionality:
in 2.16.18 lis_lockq is a _spinlock_
in 2.18.0 lis_lockq is a _semaphore_.
4. The advantage of semaphore is that while, say,
(*(q->q_qinfo->qi_putp))(q, mp) with queue locked is executed on one CPU,
the concurrent lis_lockq() attempt will give up its CPU (on 2.18.)
while the spinlock implementation will be buzzing on one CPU
when aforementioned 'put' is executed in another CPU.
So, I think, comparison is 100% justified.
Or I owe you all an apology?
> Your driver or module needed to be MP-safe under 2.16.18,
> so I don't understand why you are using the dubious q synchronization
> under LiS 2.18.
> so I don't understand why you are using the dubious q synchronization
> under LiS 2.18.
My driver is MP safe and it works just fine on 2.16.18.
> Perhaps you are just allowing your driver or
> module to default (which would be LIS_QLOCK_QUEUE), instead of
> specifying LIS_QLOCK_NONE.
> module to default (which would be LIS_QLOCK_QUEUE), instead of
> specifying LIS_QLOCK_NONE.
Assuming that I misundersood the lis_lockq concept,
where should I specify LIS_QLOCK_NONE ?
>I'd suggest the following instead:
> while ((err = lis_lockqf(q, f, l)) < 0) ;
> while ((err = lis_lockqf(q, f, l)) < 0) ;
If signal is already posted wouldn't underlying down_interruptible()
return EINTR all the time? (I probably need to look into source).
thanks a lot for you comments,
--
Eugene
Try the New Netscape Mail Today!
Virtually Spam-Free | More Storage | Import Your Contact List
http://mail.netscape.com
