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