Re: FW: Delayed Xaction and LOCK#

["Monish Shah" <monish@mcsy2.fc.hp.com>]

On Aug 27,  6:08pm, John & Ruth Pierce wrote:

> > > >> use of LOCK# should be avoided if at all possible.
>
> ....<snip>....
>
> What about the opposite situation?  Perhaps, a card which is NOT a bus
> master, only a target, that has structures in its own memory that are used
> to communicate between the host and the local processor.  If the host needs
> to update these structures, it needs to do a locked exchange of the mutex
> semaphore before proceeding...  If in fact, the cpu lock prefix doesn't
> actually lock the PCI bus between the read and write, this method is not
> safe....

On a PC with an Intel chipset, I'm sure this will work, since Intel
chipsets do implement LOCK#.  But, the lock prefix is specific to the x86
architecture.  If you are designing a card of the type described above and
you want it to be usable in all systems with PCI, you should use a
different solution.  The one I described in my previous mail still works.

I.e., the card should be designed with a hardware semaphore.  The
interface, described before, is that a read atomically grabs the semaphore,
if available and tells you if you got it.  A write releases the semaphore.
Both the host and the local processor should use that interface.  For the
hardware designer, this should be no more difficult that supporting locked
accesses to the shared memory on the card.

BTW, this is not just a theoretical discussion.  The recently introduced
C160 and C180 PA-RISC workstations from HP do not support LOCK#.  I do not
expect future HP products of that class to support LOCK# either.

Monish Shah
Hewlett Packard
£
8(