[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: Delayed Xaction and LOCK#



>> > > >> 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

I think you are correct for Intel's Pentium chipsets, but a year or so ago I was looking into this same question, and found that Intel's 486 chipsets do not propagate a local bus LOCK# onto the PCI bus, nor a PCI LOCK# onto the local bus. Since no one seems to be using PCI LOCK# at present, I'd be hesitant to depend on its implementation. Does anyone know how Pentium and Pentium Pro chipsets handle it?

--> Geoff Hickey
    Cyclone Microsystems
L<