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.
_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
