eugenelisstreams,
On Thu, 15 Dec 2005, [EMAIL PROTECTED] wrote:
>
> > 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.
>
> 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?
Same name different purpose:
int
lis_lockq_fcn(queue_t *q, char *file, int line)
{
.
.
.
if ((q->q_flag & QOPENING) || (qs = q->q_qsp) == NULL)
return (0); /* no locking, no contention */
.
.
.
int
lis_set_q_sync(queue_t *q, int qlock_option)
{
static lis_q_sync_t qsz;
lis_free_q_sync(q); /* clear out old option */
/* sets q_qlock_option to -1 */
switch (qlock_option) {
case LIS_QLOCK_NONE:
q->q_qsp = NULL;
q->q_other->q_qsp = NULL;
break;
case LIS_QLOCK_QUEUE:
default:
qlock_option = LIS_QLOCK_QUEUE;
q->q_qsp = LIS_QSYNC_ALLOC(sizeof(lis_q_sync_t), "Qsync");
>
>
> > 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.
>
> 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.
> Assuming that I misundersood the lis_lockq concept,
> where should I specify LIS_QLOCK_NONE ?
Specify it in your Config file, like so:
#
# Queue locking options
#
# 0 no locking
# 1 lock by individual queue semaphore
# 2 lock by queue pair semaphore
# 3 lock with global semaphore
#
# type name option
qlock driver loop-around 0
qlock driver inet 0
qlock driver mini-mux 2
qlock module relay 0
qlock module relay2 2
>
> >I'd suggest the following instead:
> > 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,
Your right. Better to set your qlock to 0.
--brian
> --
> Eugene
> _________________________________________________________________
>
> Try the New Netscape Mail Today!
> Virtually Spam-Free | More Storage | Import Your Contact List
> [1]http://mail.netscape.com
>
> References
>
> 1. http://mail.netscape.com/
--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
[EMAIL PROTECTED] ¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
Linux-streams mailing list
[email protected]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
