An article i've found in Dr Dobb's Journal: "Lock-free Interprocess Communication". I haven't read it in detail but it sounds appealing.
Just wanted to report it to MT (and see your reaction about it )
Lock-free IPC (seen in DDJ)
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Lock-free IPC (seen in DDJ)
just got a deeper look and, quite frankly, i'm disappointed. What the guy calls "lock-free IPC" is merely
so yes ... it's lock free ... but it will only do good job if you have actually "something useful" to do and have more CPUs than threads involved into the "chain of communication".
Code: Select all
do {
while (shared_memory[i]==0) doSomethingUseful();
ConsumeWord(shared_memory[i]);
i++;
}
- Colonel Kernel
- Member
- Posts: 1437
- Joined: Tue Oct 17, 2006 6:06 pm
- Location: Vancouver, BC, Canada
- Contact:
Re:Lock-free IPC (seen in DDJ)
I haven't read the article yet, but there is a lock-free implementation of IPC in Singularity. The catch of course is that its safety relies on certain guarantees made by the compiler regarding how IPC channels can be used.
Language Support for Fast and Reliable Message-based Communication in Singularity OS
I'll read the article now...
Language Support for Fast and Reliable Message-based Communication in Singularity OS
I'll read the article now...
Top three reasons why my OS project died:
- Too much overtime at work
- Got married
- My brain got stuck in an infinite loop while trying to design the memory manager
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Lock-free IPC (seen in DDJ)
nice article too, though it doesn't seem to be on the same topic at all, as far as i can tell.
- Colonel Kernel
- Member
- Posts: 1437
- Joined: Tue Oct 17, 2006 6:06 pm
- Location: Vancouver, BC, Canada
- Contact:
Re:Lock-free IPC (seen in DDJ)
Exactly. Isn't that why you were disappointed with the DDJ article (because it wasn't about implementing general-purpose IPC in an OS)?
Top three reasons why my OS project died:
- Too much overtime at work
- Got married
- My brain got stuck in an infinite loop while trying to design the memory manager
Re:Lock-free IPC (seen in DDJ)
But... but... aren't we all going to use 100-CPU multicore systems any day now? ;DPype.Clicker wrote: ...it will only do good job if you have actually "something useful" to do and have more CPUs than threads involved into the "chain of communication".
(Oh yes, it's so easy to ignore algorithm issues and let the hardware progression solve them... hello Windows. )
Every good solution is obvious once you've found it.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Lock-free IPC (seen in DDJ)
no. More because i expected it to present some kind of "new" technique for IPCs and it just appeared to be a old technique you've shown in CS courses to illustrate the need for synchronizing atomic functions in an OS (in order to avoid time wasted in polling loops).Colonel Kernel wrote: Exactly. Isn't that why you were disappointed with the DDJ article
Re:Lock-free IPC (seen in DDJ)
lockfree IPC: use locked bus transactions. They're atomical by nature. Okay, locked bus transactions aren't actually lock-free but at least they don't lock much.
Hm... Thinking of it, lock-free is impossible by definition, except in cases where you use them rather as deferred cothreads. Using an OS that has a yield_to(xyz) function allows that, you allocate space for one item, produce one item and store it, then if it is full, you yield to the consumer(s). Dito for consumers, when it's empty, you yield to the producer. Assuming quick thread switches, this is darn fast.
Hm... Thinking of it, lock-free is impossible by definition, except in cases where you use them rather as deferred cothreads. Using an OS that has a yield_to(xyz) function allows that, you allocate space for one item, produce one item and store it, then if it is full, you yield to the consumer(s). Dito for consumers, when it's empty, you yield to the producer. Assuming quick thread switches, this is darn fast.