10 Mar 2007 (updated 18 May 2008 at 07:14 UTC)
»
Message passing? Yes!
lkcl
posted a
reply to my
previous post...
Oh, lkcl, you're a bit of a pessimistic, there.
unlink is also atomic, not just
rename. ;-)
But what I'm looking after right now isn't just a general message-passing operation (I already do that at a higher level, between various subsystems, using shared memory for local or sockets for remote recipients), more specifically the best way to take advantage of multiple cores as much as possible to process file descriptor events.
You have to cut the libc people some slack, though, they don't have locks around
every single functions. I'd be amazingly appalled if
strncmp() took a lock, for example! And as I described, I already used processes and shared-memory for higher-level concurrency, this threading is only for the very lowest level, when I have no choice and I'm pushed to the edge. Note that the code is already written as a state machines, using the threads to run more than one state machine at once (there is one state machine per connection or so, more or less). I'm planning on having a lock on the state machine instance, so that a single state machine cannot be executed on more than one thread at once, so that the code inside of it can make that assumption (that still allows me to handle multiple independent connections at once).
On Linux,
epoll already does that in an atomic way, for me, in its edge-triggered mode. You can just have multiple threads call
epoll_wait(), a given event will be sent to only one thread, until it is re-armed. But the specific requirement here is "compatibility layer for portability to other POSIX platforms", hence the use of crummy old
select(). Of course, if I need high-load scalability on some big iron, I'll be sure to
not use that layer, and go for
epoll,
kqueue() or something like that!
That said, I'd like a link to that message-passing work, it sounds interesting.
Syndicated 2007-03-10 18:49:00 (Updated 2008-05-16 18:47:53) from Pierre Phaneuf