It doesnt quite work like that anymore. You could design a system like that yes, but...
So lets say we are talking about DRAM, you have a dram controller, a dram reference clock for that controller, there are standard parameters the controller knows about but are specific to that vendors chip (although they are pretty much the same numbers for a particular technology and speed across vendors). The dram (ddr) plug in modules also include a small rom/flash that includes the parameters for those modules, the software reads that using i2c for example, using that information it causes the controller to train with the dram and find a speed and settings that will work. Now the controller knows the speed and other timings for that memory so when the processor via some controller in between and caches, etc, asks for something from dram, the dram controller knows how fast it can talk to it.
sram when you are talking at these speeds is similar you have a bus that you need to tune or train, normally not every boot though, dram is generally in plug in modules, sram soldered down, so the board vendor tunes that interface and using its bootloader gets that interface, up but in that case as well the sram controller now knows the speed to talk to the sram.
The procesor busses are not like the old days, you to some extent can/do have separate read address, read data, write address, and write data busses. the other side of that bus is a controller that queues up commands from the processor as there can be many in flight, and then sorts them and sends them down the right path. the processor may put out a read address request with a read id, some unique number on that part of the interface, the other side queues that request, and acks it, this allows for credits between the two so the processor doesnt overload the read command fifo. At some point when that read gets to the front of the queue, then it gets interpreted and sent along its way (based on the address bits of course). If that happens to be dram it gets sent, ideally through a cache so that the dram side is more efficient, but doesnt have to if you want to read one byte then you will read a whole 64 bits from the dram, send all 64 back or maybe 32 depends on the bus widths. and the processor based on features of that bus will isolate the byte it asked for, the buses and controllers, on a read wont normally know if it is actually only one byte, it is one bus width. Note the read data bus was involved the controller got the data from dram, then has to tell the processor, hey I have read id number 7 data for you. The processor queues up that request, when it has time it says, okay you can send me read id number 7 data. and then takes it.
write pretty much the same but it is one direction and fire and forget, write address request goes out, gets acked, queues up in the bus controller, eventually the bus controller asks the processor for the data from that write id, queues up, processor eventually says here is the data, then the controller now has everything it needs the address, data, transaction type, (exclusive, cacheable, write bufferable, etc). Other bus features are required, you can probably do byte addressable transactions so there will be a scheme to identify the byte or bytes on the bus that are real, the rest are garbage, and if it is not a bus widths or dram widths worth of data the dram controller has to do a read-modify-write to read the width, modify the byte or bytes in question, and then write them to dram. a cache can help here as it isolates this everything on the dram side is ideally in multiple units of the bus width, and stuff on the processor side can be that or less, the cache is faster so the read-modify-writes are less costly. at the same time though you need the data in the cache so you might have to read a bunch of data, in order to write one byte, on the first access to that cache line if it misses. then later write some number of bus widths even if that one byte is the only difference when it is evicted.
so with a modern processor (x86, arm, etc) with a modern bus, the simples transactions can take many to dozens of clock cycles, when you touch dram even if 2133Mhz it is still really slow and can take tons of clock cycles, dozens, hundreds.
So to your question, it depends on the memory interface, it is very unlikely that the processor has any clue what is at any address, it doesnt know memory from flash from a peripheral to a hole in the wall, only the programmer knows that. the processor just performs the instructions it is given at the addresses given. The board/chip designer has implemented the address space and from that the memory side is managed by a memory controller and that memory controller is configured by the programmer for the proper speed memory for that board design, or by a detected method if it is removable memory. When the processor does its request even if a simple wishbone bus, the memory controller will eventually get hit and it will take as long as it takes to perform the transaction and ack back or return data. Writes can be but not always are fire and forget, the processor can send out the address and data and it is done it can move on to the next task. Reads require the round trip the processor has to wait for the address to go all the way out and wait for the data to come all the way back. so writes are fast for random access, for sustained stuff though they both are throttled by credits between fifos and the speed of the memory ultimately controls the speed of the traffic jam.
If you are talking about the old days like 8088 the memory had to be as fast or faster than the processor and there were no wait states, then later wait states were allowed but the logic that attached to the processor would be designed to request the wait state. If you were to do a modern design with a traditional bus, then you would likely have a programmable memory controller and on boot the software would configure the controller based on knowing the board design or some detection mechanism, and then the memory controller would request the right amount of wait states based on that configuration.
this is all very vague since you have not provided enough detail for a specific answer.