RE: Avoiding deadlock in iSCSI

["GUPTA,SOMESH (HP-Cupertino,ex3)" <somesh_gupta@am.exch.hp.com>]

David,

I agree that any of the various forms of synchronization will work
(note the command numbering)

Somesh

-----Original Message-----
From: David.Robinson@EBay.Sun.COM [mailto:David.Robinson@EBay.Sun.COM]
Sent: Tuesday, September 12, 2000 11:58 AM
To: ips@ece.cmu.edu; somesh_gupta@hp.com
Subject: RE: Avoiding deadlock in iSCSI


> If we are using multiple connections, this requirement has
> ramifications on the implementation on SMP systems. The initiator
> will be sending command on one connection, and data on another
> connection, which are two different actions. To ensure ordering
> would require taking a lock across the two actions (or otherwise
> ensuring that they always happen on the same CPU). This would
> be quite expensive actually.

I disagree. You need to maintain a current command counter
and for each connection a last sent counter.  As with
any multithreaded application you need to use locks to
protect shared data structures. For commands you just get
your command number, check the command connection last sent
counter, if your command is next you send it, otherwise you set
a conditional variable and sleep on it, when the current sender
finishes it simply wakes up any waiters. Same for data connections,
with multiple data connections the sender could do a simple round
robin and actually get less contention than on the command connection.

	-David