in c#, "lock" is a method to avoid racing condition, avoid multiple threads read and write to a shared variable between them.

lock usually will cause delay, lets say 1 thread locked and accessing a variable(and process until it unlock), all others thread cant lock, they all have to wait(or stuck) until somebody else lock, unlock, and wait until they able to lock(access the variable)

i wonder if there is alternative, like i want to know if the variable is locked, if its, pass, try it again next time, still lock, pass, basically i dont want certain thread get delay when they cant access a variable.

Look for lock with timeout solution for C#.

cant wait, want to do as fast as possible, but i just noticed that "byte" operation is atomic, means if you just use 1 byte as variable, multiple threads can read and write on that byte, you dont need to worry about lock or race condition. so 1 byte is limited to 256 possibilities.

atomic increment & decrement, and checking are another "syncing" operation. But yeah, what you need seems like a timeout.


[update] Interlocked.CompareExchange , Interlocked.Increment .. etc... search under this namespace.

This post has been edited by dstl1128: May 24 2024, 12:07 PM

In C, you can use atomic int as a flag, which does not involve sync at all since it is just a single assembly instruction. So if this flag is set, then your thread can do something else.

so, you already got solution for your question?

mind sharing?

i did ask chatgpt is about the question

"If you want to avoid blocking threads when accessing a shared resource, Monitor.TryEnter, Interlocked.CompareExchange, and SemaphoreSlim are great alternatives to using the lock keyword. They allow threads to try and acquire a lock or access a resource without getting blocked. Each approach has its strengths, and the best choice depends on your specific use case, whether you need to ensure atomicity of operations, or if you are working in an asynchronous environment."

Yeah, I’ve run into this issue before when I wanted to avoid threads getting stuck waiting for a lock. Instead of using lock, you can try Monitor.TryEnter(). It lets you check if the variable is locked, and if it is, the thread just skips instead of waiting around. I used this in a project where performance mattered more than ensuring every thread got immediate access to the resource. Here's the gist: you wrap your code in a try block when TryEnter succeeds, and make sure to call Monitor.Exit() in the finally. It worked for me, but you’ve gotta be okay with some threads not always getting the resource on every pass.