GO/TESTS: Use serialized thread mode

[tvegas1]

What

Seems goroutines can end up being scheduled on different OS threads.

Why ?

When used in single thread mode, UCX must be always running on the same thread.

[rakhmets]

What issue is being solved by these changes?
I guess you need runtime.LockOSThread(). Because this is the only way to force Go to use the same thread.
Please take a look at #9581.

[tvegas1]

What issue is being solved by these changes?

The goroutine is being run on different OS threads, which ends up operating UCX worker on different OS threads.

Doing so can cause corruption. For instance, in single thread mode for IB, we use bf_post instead of bf_post_mt which skips using a store fence when sending data. I am not aware of any other difference apart this added barrier.

We then added #9918 to enforce single thread usage, which is now triggering issue in go tests.

I guess you need runtime.LockOSThread(). Because this is the only way to force Go to use the same thread. Please take a look at #9581.

Agree there is similarity, but here we don't even need to be as stringent. Having the worker being freely non-concurrently operated from multiple OS threads is fine (the goroutine), as long as we create it in serialized mode.

[brminich]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[brminich]

wire-compat failure is a known issue related to a specific server config

[brminich]

merging this PR to unblock CI