Oleg,
lis_strqset already locks the queue if band structures are involved. Locking
before lis_strqset is not necessary. lis_strqset is MP-safe. You only might
need to do that if you were doing
LIS_QISRLOCK(q, &flags);
strqset(...)
strqset(...)
strqset(...)
strqset(...)
strqset(...)
strqset(...)
LIS_QISRUNLOCK(q, &flags);
and you wanted all the strqset's together to be treated atomic.
Otherwise you can get away with just:
strqset(...)
--brian
On Wed, 01 Oct 2003, Oleg Kodel wrote:
> I freeze the q before strqset (for of chainging water marks and packet size
> boundaries).
> So, I think the
> LIS_QISRLOCK(q, &flags);
> strqset(...)
> LIS_QISRUNLOCK(q, &flags);
> Is acceptable solution.
>
> > -----Original Message-----
> > From: David Grothe [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, September 30, 2003 10:10 PM
> > To: [EMAIL PROTECTED]
> > Cc: Oleg Kodel; '[EMAIL PROTECTED]'
> > Subject: Re: [Linux-streams] Freezestr() analoug in the LIS
> >
> >
> > In LiS, upon entry to a put or service procedure the running
> > thread holds a
> > lock on the queue that is passed in as a parameter (not the queue
> > pair). While this STREAMS routine is running, other threads
> > may use putq
> > or getq on the queue with no blocking. But another thread
> > cannot do a
> > putnext() into the queue or cause the queue's service
> > procedure to be invoked.
> >
> > So the stream is about "half frozen" implicitly. Depending
> > upon what Oleg
> > wants to do, that may be good enough. If he is reaching into
> > the queue and
> > manipulating structure elements that the STREAMS executive
> > also manipulates
> > then he is playing with fire, freezestr() or no freezestr().
> > If he is
> > simply trying to accomplish exclusivity of access to the
> > queue between
> > members of his own family of drivers then a private lock
> > would be more
> > appropriate.
> >
> > The Solaris documentation on freezestr() says, in part:
> >
> > >There are usually better ways to accomplish things than by
> > freezing the
> > >stream.
> >
> > So I am regarding this as a low priority change.
> >
> > -- Dave
> >
> >
> > At 02:24 PM 9/30/2003 Tuesday, Brian F. G. Bidulock wrote:
> > >Dave,
> > >
> > >Just dummying out would be dangerous on MP. For LfS I take
> > a read lock
> > >on the stream head and take a write lock on queue saving local irq
> > >flags in the queue_t structure. For unfreezestr I undo the
> > two locks
> > >and restore irq flags from the queue_t structure. I save
> > the isr flags
> > >in the queue structure to preserve the prototype for
> > freezestr(queue_t
> > >*q) and unfreezestr(queue_t *q).
> > >
> > >freezestr must lock out at least putq, putbq for the queue until the
> > >stream is thawed.
> > >
> > >Even though LiS appears to single thread put and srv and locks out
> > >local interrupts while either of these are running,
> > interrupt service
> > >routines on another processor performing putq to the
> > supposedly frozen
> > >queue could cause serious problems.
> > >
> > >In LiS it would be closer to take the LIS_QISRLOCK on the queue for
> > >freezestr and release it with LIS_QISRUNLOCK on unfreezestr.
> > >Unfortunately these functions need a pointer to an int as an
> > argument
> > >as well. So,
> > >
> > >{
> > > int flags;
> > > LIS_QISRLOCK(q, &flags);
> > >
> > > ...
> > >
> > > LIS_QISRUNLOCK(q, &flags);
> > >}
> > >
> > >is roughly equivalent to:
> > >
> > >{
> > > freezestr(q);
> > >
> > > ...
> > >
> > > unfreezestr(q);
> > >}
> > >
> > >in that it at least locks the queue. freezing a stream is really
> > >supposed to lock all the queues in the stream, but at least this
> > >protects the queue whose internals are being manipulated.
> > >
> > >In Linux Fast-STREAMS I have:
> > >
> > >void freezestr(queue_t *q)
> > >{
> > > unsigned long flags;
> > > hrlock(q);
> > > local_irq_save(flags);
> > > write_lock(&q->q_rwlock);
> > > q->q_iflags = flags;
> > >}
> > >
> > >void unfreezestr(queue_t *q)
> > >{
> > > unsigned long flags = q->q_iflags;
> > > write_unlock(&q->q_rwlock);
> > > local_irq_restore(flags);
> > > hrunlock(q);
> > >}
> > >
> > >to preserve the prototype. It also read locks the stream
> > head to keep
> > >I_PUSH, I_POP, qopen and qclose from altering the stream
> > configuration
> > >and protects reading the q->q_next pointer as well.
> > >
> > >--brian
> > >
> > >
> > >On Tue, 30 Sep 2003, Dave Grothe wrote:
> > >
> > > > These are not implemented in LiS. Just provide dummy
> > routines when
> > > > compiling for LiS.
> > > > -- Dave
> > > >
> > > > At 06:49 AM 9/30/2003 Tuesday, Oleg Kodel wrote:
> > > > >Is it some freezestr()/unfreezestr() (SVR4) analogous in the LIS?
> > > > >
> > > > >This e-mail message has been sent by Elbit Systems Ltd.
> > and is for
> > > > >the use of the intended recipients only. The message may contain
> > > > >privileged or confidential information . If you are not the
> > > > >intended recipient you are hereby notified that any
> > > use,
> > > > >distribution or copying of this communication is strictly
> > > > >prohibited, and you are requested to delete the e-mail and any
> > > > >attachments and notify the sender immediately.
> > > > >
> > > > >_______________________________________________
> > > > >Linux-streams mailing list [EMAIL PROTECTED]
> > > > >http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
> > > >
> > > >
> > > > _______________________________________________
> > > > Linux-streams mailing list
> > > > [EMAIL PROTECTED]
> > > > http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
> > >
> > >--
> > >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
> >
>
> This e-mail message has been sent by Elbit Systems Ltd.
> and is for the use of the intended recipients only.
> The message may contain privileged or confidential information .
> If you are not the intended recipient you are hereby notified that any use,
> distribution or copying of this communication is strictly prohibited,
> and you are requested to delete the e-mail and any attachments
> and notify the sender immediately.
--
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
