two arduino's share external flash ram/eeprom/sd card?

While I don't need this (strictly speaking) it would be convenient to have it one location...

One arduino would write a byte to memory, and another would read the byte (or file on sd); so there is no worry about needing a locking mutex.

Is it possible (feasible, easily doable, if so how?) to have two arduino's talk to one/shared eeprom or sd card?
I imagine that if sd card and SPI, I would need some sort of mux chip to 'hide' the source ("address 0") is doing the read/write, so that the sd hardware thinks it's the same system all the time. Conceptually it seems like it might work; but it seems just complicated enough there are probably things I am missing / not seeing.

SPI and SD cards by extension, doesn't have source addresses. Whatever device is currently driving the CLK line is the master and all the slaves can listen in on the conversation. The CS line is what permits one slave to drive the MISO line.

If you set up two Arduinos and one SD card then you would have to be careful that only one Arduino would talk at the same time. Perhaps a dedicated CS type line between the two of them. Then you would have to make sure that every conversation with the SD card always properly closed the file that was open.

It wold be quite slow and prone to error. It would be better to have only one Arduino in charge of the SD card and another communication channel like I2C or Serial between the Arduinos.

You can use e.g. an EEPROM with I2C interface, connected to both controllers. The I2C protocol will handle concurrent access~~, when the SCL (clock signal) is wired AND (open collector and pullup resistor)~~.

One way I would deal with this is to have an external shared clock (say a 1Hz signal from a RTC) and define a synchronized time for both arduinos (could be two or more) to have access to the card.

Say
Arduino A would access on odd seconds
Arduino B would access on even seconds
...

You would need to make sure the read time never exceeded the allocated time frame or at least check the CS line before trying to use the card, just in case on hangs and keeps the card busy.

The idle arduino should have the SPI peripheral disabled and pins set as inputs so as not to have any effect on the device acting as master

What kind of application is this for?

How much memory are you considering sharing?
Using SPI would be fast, with each device either monitoring CS to see that it's not active, then enabling SCK/MOSI onto the common lines to do their thing. Or time phase as suggested above, or use a pin from master to slave that's indicates "hey, I'm done, do your thing" and if it goes active the slave has to terminate it's transfer until the master indicates it's done again, and the master can give it a uS or two to finish up or something. Many ways to get there.
Use FRAM for SRAM's access speeds and EEPROM's non-volatility.

SD card would be larger in storage capability, but more prone to corruption as the SD processor adds its own complexity for completing buffered reads & writes.

Thank you for the infos. ideally, one bit shared, or a byte. the smaller the better -- as I only need to know 1 bit of information.

daveyjones:
Thank you for the infos. ideally, one bit shared, or a byte. the smaller the better -- as I only need to know 1 bit of information.

For such a small amount of information an FRAM would likely be more suitable, and cause less overhead than a SD.
The SPI Versions are dead easy to interface, I2C A little harder, but not too bad either.

Thanks. I'll have a look at FRAM.

One bit of information? Then use one wire. No storage chip required.

Well, actually two wires would be more practical. That way each Arduino has an "input" that it knows comes from the other Arduino.

MorganS:
Well, actually two wires would be more practical. That way each Arduino has an "input" that it knows comes from the other Arduino.

That was my idea as well, for a single bit.

When one controller wants to change the shared bit, it sets its output pin to the new state. The other controller detects the change on its input pin, accepts and adjusts its output pin to the new state.

The simplest solution is often the best... Thanks! That's so obvious I completely missed it.