Re: LiS-2.18.0: message loss problem

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 ¦