Re: concurrent linked queue class for C++?
"Branimir Maksimovic" <bmaxa@hotmail.com> wrote in message
news:hgs21l$pm0$1@news.albasani.net...
Andrew wrote:
I am designing a system where an app will need to spawn a child thread
then the child and parent thread will need to communicate. If this was
in java I would use ConcurrentLinkedQueue but what to do in C++? I
have googled and searched boost but cannot find anything.
There is a class that would serve in ACE but ACE is huge so I do not
want to introduce ACE to the project. The project is already using
boost and fighting the battle for more boost usage is hard enough.
Does anyone know if such a facility is planned for the upcoming std?
I would advise against using threads. Processes and shared memory is
much more easier to maintain,
I am curious as to what made you come to that conclusion? Anyway, which one
is easier: Creating a dynamic unbounded queue with threads or shared memory
and processes? With threads you can get this done rather easily using
pointers. For instance, with threads the nodes and queue anchor might look
like:
_____________________________________________________
struct node
{
struct node* next;
};
struct queue
{
struct node* head;
struct node* tail;
intra_process_mutex mutex;
};
_____________________________________________________
With processes you are probably going to need to use *offsets off a base
memory; the queue might look like:
_____________________________________________________
struct node
{
size_t next;
};
struct queue
{
size_t head;
size_t tail;
inter_process_robust_mutex mutex;
unsigned char* base;
};
_____________________________________________________
and you get at the actual nodes by adding the offsets (e.g., node::next,
queue::head/tail) to the base memory (e.g., queue::base) that the process
mapped the shared memory for the queue to. Also, with processes you might
need to handle the case in which a process dies in the middle of accessing
the queue. IMO, it's normal for a process to die in general, however, it's
NOT normal for a thread to just up and die. This is why there are such
things as so-called robust mutexs for process synchronization. You have to
deal and fix up possible data corruption from the queue data-structure being
left in an intermediate state by the dead process.Therefore, IMHO, threads
are easier for me to work with than multiple processes.
[*] - This is only true if you cannot guarantee that each process maps
memory at the _exact_ same base address.
no threading problems and performance
you gain from threads does not matter because there is always
something slow like hard disk and database which will make
no difference between processes and threads.
Shared memory and processes should be equal in performance to threads if you
can use pointers. With the offsets you need to perform an addition in order
to get at the node data-structure; something like:
_____________________________________________________
struct node*
queue_get_head(struct queue const* const self)
{
return (struct node*)(self->base + self->head);
}
_____________________________________________________
Ahh, but you have to setup a special offset value for NULL. Perhaps:
_____________________________________________________
#define NULL 0xFFFFFFFFU /* assume 32-bit system */
struct node*
queue_get_head(struct queue const* const self)
{
if (self->head == NULL) return NULL;
return (struct node*)(self->base + self->head);
}
_____________________________________________________
Why would you think that all that is easier than using threads? What am I
missing here?
Thanks.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]