Conflict resulting in serialization when multiple warp blocks access (read) the same shared memory v

Hello,

If a shared memory variable can be broadcast to threads within a warp block for devices of sufficient compute capability, what happens in the case where (threads from) multiple warp blocks of the same kernel wish to read the same shared memory variable, assuming that the warp blocks arrive at this point more or less the same time?
Would it result in serialization across the warp blocks or not?

shared mem is only shared within one thread block.

there is no way that multiple thread blocks are going to read from the same shared memory location.

as for multiple warps (within the same threadblock) reading from the same location: they aren’t executed simultaneously as far as I know. Dual issue won’t occur for operations that cannot be sent to different execution units (so two warps doing shared memory reads most likely won’t be dual issued)

problem solved?

perhaps I should have stated …warp blocks of the same kernel block… instead of just …warp blocks of the same kernel…; I am referring to your latter point: multiple warps (within the same threadblock)

If I interpret your latter point correctly, you imply some form of serialization would occur: the shared memory variable would be read for the warp blocks one at a time, and cannot be read for all warp blocks at once…?

Yes, it results in serialized access to that location in memory. The only case where that doesn’t happen is if they all read from the same location, which is then broadcasted.

Forgive me, but your answer is somewhat vague

Are you saying that, over and above and in addition to the shared memory variable being broadcast to threads within a wasp block, that the same shared memory variable can also be broadcast to multiple warp blocks (of the same kernel block), simultaneously, if multiple warp blocks wish to read the same shared memory variable, as this is really what I am trying to grasp

I ask this because it is something my algorithm currently does frequently, and it may be better to attempt to avoid this if possible, if it comes at a cost