tag:blogger.com,1999:blog-5246987755651065286.post7227483085507768144..comments2024-02-22T16:15:42.388-08:00Comments on cbloom rants: 01-21-09 - Towards Lock-Free Threadingcbloomhttp://www.blogger.com/profile/10714564834899413045noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-5246987755651065286.post-54126429727813498692009-01-21T22:43:00.000-08:002009-01-21T22:43:00.000-08:00(Did you change the settings on your blog comments...(Did you change the settings on your blog comments? I had to use a google account to post this, I was using OpenID before...)<BR/><BR/>I don't really understand your approach... with a mutex'd communication region, you can do stuff like "lock; read value; depending on value do various if()s and write one or another value; unlock". I don't see anyway you can do that under a network delta model, so it seems like you're actually talking about some very specific narrow model, not just 'communication region with a mutex'.<BR/><BR/>I tend to model shared information as "owned". There's a given chunk of memory that is owned by one thread. One atomic unit of the memory indicates ownership; all threads can read it, but either zero or one can write it. Then the rest of the memory of the chunk can only be read by the owner.<BR/><BR/>For the "zero-or-one can write it", there's really just two cases: either one thread owns it and only it can write the atomic field (and read/write the rest), or else it's unowned, and any other thread can take ownership of it (but they need to mutex or use an interlocked operation to do so). If you take ownership of a chunk, you need to do a read barrier before reading the rest of the chunk; and vice versa for the owner of the chunk giving up ownership.<BR/><BR/>I don't know if this is a sufficiently general model, but in the threading stuff I've done it's always been good enough.<BR/><BR/>So e.g. you can make jobs by somebody creating a job data structure which they own, then releasing ownership of it (to be accessed by work threads) by e.g. setting a flag field to 'READY TO BE WORKED ON'.<BR/><BR/>Implenting a circular queue holding jobs can also be done under this model; you use two chunks that are just the head/tail of the queue. If there's only one writer, it's the sole owner of the head so no locking is needed to add to the queue; otherwise a thread adding to the queue needs to take ownership of the head field to update it (which means using locking). If there's only one reader, it's the sole owner of the tail so no locking is needed to remove jobs; otherwise you need to take ownership to remove.<BR/><BR/>Anyway, I don't see any way to implement this model in the approach you're talking about. Maybe that's because this model isn't adaptable to lock-free operation, but I'm not clear what model *does* scale from using mutexes on communication regions to a 'network messaging' model.Sean Barretthttps://www.blogger.com/profile/14465498859800664552noreply@blogger.com