RejectedSoftware Forums

Sign up

Pages: 1 2

Re: General questions on implementation

On Wed, 11 Dec 2013 06:23:15 -0500, Shammah Chancellor wrote:

What do you mean? Is there a good way to avoid locking for shared resources?

-Shammah

If by "good" you mean "easy" / "reliable" - no, there isn't. Using concurrency efficiently is very hard and task-specific. I honestly think it is one of hardest things in modern programming. I keep learning new techniques all the time as most of my jobs were tightly related to concurrent request handling and there is always some use case where one specific approach shines. No silver bullet, sorry.

Exact scenario I was referring to is when you have multiple worker threads processing requests such that each does A -> B -> C and B implies locking some shared resource / intensive computation. Such code can be redesigned to instead have a separate thread that is only devoted to doing B and receives context for it from worker threads via some sort messages (I think vibe.d Isolated should help to do it efficiently). It is generally more beneficial because:

a) if processor affinity is set for such thread, instruction cache will almost never be invalidates. It does matter
b) As now it is only thread that works with "shared" resource, no explicit locking is required.

Such imaginary application will work that way:

Thread 1 : receive context message -> B -> reschedule request as marked for C
Thread 2..N : receive request -> A -> reschedule request as marked for B

  receive context message -> C -> response

(A and C can also be possibly separate of course but it is all up to testing / profiling)

Re: General questions on implementation

Sorry, formatting.

Thread 1    : receive context message -> B -> reschedule request as marked for C
Thread 2..N : receive request -> A -> reschedule request as marked for B
              receive context message -> C -> response

Pages: 1 2