It is perfectly possible for two masters to send a start bit at exactly the same time, where with exactly I mean that the difference between the start bits falling fronts is smaller than the smaller measurable difference by the masters.
That's the point: when a master is writing on the i2c bus it is also monitoring it, thus it is possible to determine if a collision is occurring.
Let's say that two masters, A and B, connected to the same bus, want to address two different devices, one with address 0xAE (from A), the other with address 0xA6 (from B). The masters send the start bit at almost the same time, then begin sending the address. Since 0xA = 0b1010 they send the sequence 1010, so far so good, but 0xE = 0b1110, while 0x6 = 0b0110. The fifth bit differs, and A tries to send a 1, while B sends a 0.
Who wins? B of course, because i2c is an open collector bus, lines can only be tied low. To send a 1 you just turn off the output and an external pull up resistor ties the line high, while to send a 0 you turn on a pull down. Master A then is sending a 1, but measuring a 0. Big red flag, bus collision! Master A state machine should properly handle the situation, leaving the bus to B.
Please note that from B point of view nothing has happened, and it continues happily with the frame. That is very good because no time is lost and B can do whatever it needs to do.
While it seems that an open collector bus is the solution to all the problems, unfortunately it is not so. The bus can easily be blocked by any malfunctioning device that decides to hold SCL or SDA low. In such situations it is very difficult to reset the bus, sometimes devices have a reset pin, sometimes you have to power cycle them, sometimes you have to think of something even different. Had to do all the three in different applications.
As a side note be aware that not all masters implement the full spec, some masters do not implement bus collision detection and this can be very bad. In the previous example, if nor A nor B can detect loss of arbitration the address sent on the bus is 0b10100110, i.e. B slave address, but when the ACK comes A thinks it comes from its slave, and after that things can get very bad.
There also is the possibility that A and B wants the same slave. If this happens the ACK is received, and then many things can happen.
Usually i2c devices have many registers that can be written and/or read, the communication frame then looks something like:
slave address; ACK; reg address; data;
(Omitting start and stop bits and WR bit).
The masters start sending the register address. If they want to access a different register it just happens what would happen for the slave address: at a certain point one of them detects the loss of arbitration and gives up.
If the masters want to access the same register, or the i2c device has a default behaviour like "if I detect my address I'll tell you the temperature", then... Everything is perfectly fine! Both masters wanted exactly the same thing, and they are getting it, and this is OK per the standard.
Two communications in only one frame, take that Nyquist!
Best Answer
A device which is a pure I2C slave can not start an I2C transaction. This holds for both multi- and single-master I2C buses.
However, some slave devices can alert the master out of band, not through I2C. When the master sees the alert, it will initiate the transaction. For this purpose, some ADCs have discrete digital outputs which correspond to the state of the A/D conversion. (For example, the AD7998 has got an ALERT/BUSY pin and an I2C connection for readout and configuration.)
If there is a multi-master bus, then a device could switch its role on the fly from master to slave. Then it can initiate an I2C transaction as a master. It would have to be a microcontroller with its own firmware. The vast majority of hard I2C devices are bus slaves, although there are a handful of hard I2C devices that are bus masters. I've never heard of a hard I2C device that would switch from master to slave.
By the way, here's a related thread: https://electronics.stackexchange.com/a/232135 .