I'm quite OK with that. Making it easy to write code just makes the harder problems easier, so you will still have hard problems to work on, but the easy problems will be solvable by anyone. That's how frameworks are developed. You build a layer of abstraction (lower one) so you can work on the more complicated next level.

Haha, so true. C++ has a terrible and outdated compilation model, that is plagued by poor (see: none) dependency analysis, but of course the hardcore C++ guys don't want to admit it, which is probably why you got rated down.

And you can't do #2 when you're watching an internet broadcast? That is, hit the mute button on your player, and read a book in the meantime? So many gripes. Just sit back and enjoy life.

So, boost is a great library that has a lot of neat stuff, but I'm looking specifically for a multi-threaded smart pointer implementation, one that can even be as simple (it doesn't need to be blazing fast) as "lock, increment/decrement count, release", which seems like it would be easy to do. Smart pointers can be tricky though, so I'd like to find a good common implementation before giving up and doing something homebrew. Any ideas?

I see what you mean. The second interlocked operation was removed (because it was more or less useless for a real data structure), but the implementation could be better. Thanks for the tip.

I guess you can do this if you use GDB from the command line, but too bad it doesn't work well from the debugger frontend. Thanks for the suggestion, I'll see if there's anything else that can be done.

Back in the day, when I used Visual Studio on Windows, you could break on any exceptions or abrupt termination. With Netbeans and Linux C++ development, however, it seems like I have 3 options: Pass and continue (terminates the program), discard and stop, discard and continue. None of these do anything remotely useful. Discard and continue is probably the most useful one, in that it lets you keep on going until you hit a segmentation fault. My goal is to figure out which line of code is causing the initial SIGABRT. Any suggestions?

I've seen that series of documents, although I haven't considered it for my implementation, though I don't think it really solves the problem I have of trying to make "push/pop and signal" atomic. It does however seem like it would have better performance than the standard locked queue. Thanks for bringing it up.

You need to make your two actions atomic - the only way to do that is to serialize access to a combination of work queue and event, using a mutex or critical section. I sort of figured that might be the case. If the overhead of calling critical section is significant compared to amount of work being done in the thread, your work items are much too small. What I use for work items is something in the order of a hundred multiplications/divisions. So, for instance, say I want to multiply two square matrices matrices or equal size using the naive method, I split up the work so that each entry of the resulting matrix is a single work item. If I have a 100x100 matrix multiplied by a 100x100 matrix, then that gives me 100 multiplications and 100 additions for each of 100x100 (10000) work items. This seems to really stress my threadpool implementation since the single-threaded version of this naive matrix multiplication is a lot faster, and it's definitely due to the overhead of my threadpool. I was thinking that a more efficient use of synchronization (if possible) might alleviate this problem, however, I haven't actually extensively profiled my program. What I do know, however, is that the vast majority of the time is being spent on queueing the work, rather than doing the actual work. A different way might be for the thing that's pushing the work to select the thread that's to do the work and, by having an event per thread, signal the selected thread to pick up a work item. If there are no waiting threads, do nothing. And when a thread enters a waiting state, it can look at the work queue before entering the waiting state and pick the next work item. OK, that's some food for thought. I'll think about this and see if I can implement something accordingly. Thanks for your comments.

The problem with my custom threadpool (fun activity, not commercial) is this: I have, say 5 threads running, a global counter of how many pieces of work there are, and a work event which should be unsignaled (reset) when there is no work, and signaled (set) when there is work, because when there is no work, the threads simply wait on this event. I have two methods PushWork() and PopWork(). PushWork() increments the global counter by 1 using an interlocked operation, and checks "if I just incremented the global counter to 1, SetEvent()". PopWork() decrements the global counter by 1 using an interlocked operation, and checks "if I just decremented the global counter to 0, ResetEvent() and wait on the event". The problem is a race condition. Imagine if the work queue is currently empty. PushWork() gets called, and increments the counter to 1. Then, PopWork() gets called and decrements the counter to 0. PopWork(), running faster than PushWork() (for whatever reason) resets the event. PushWork(), chugging along, then sets the event. Now, we have a no more work in the queue, but the event is set, so the threads keep polling the queue for work. There is a similar problem for the other way around. Imagine if the work queue currently has one item. PopWork() gets called, and decrements the counter to 0. Then, PushWork() gets called and increments the counter to 1. PushWork() sets the event. PopWork() resets the event. Now, there are work items in the queue, but the threads will stop running as soon as it hits the event. The reason why this can occur is because modifying the counter and setting/resetting the event are not atomic. I could simply wrap both of these with a critical section, but I think the overhead is too big, since it means that for every piece of work, there are two EnterCriticalSection() calls and two LeaveCriticalSection() calls, one for each of push and pop. I've been trying to find a way to do this without locks. Does anyone have any ideas? INFO: I use a combination of global work queues and local work queues (one per thread) as per modern threadpooling implementations with work-stealing queues. I do, however, have one global counter for all the work. I've entertained the idea of using different counters but don't see how that would solve my problem.

I've never worked with fibers so I don't actually know. I see that they have a neat little API for some of the stuff that I might want to do, but that may not be sufficient. With respect to working with fibers, I'm starting from ground zero here. :) I've also read a lot of articles warning very heavily against their usage, bugs, limitations, and etc. It's not too encouraging but still tempting, which is why I ask for some feedback.

I don't exactly have a game plan for how I will handle fibers and waits so part of the task would be for me to see if the Windows API has any kind of built-in support for this. If I can somehow accomplish that, then I don't think the scheduling would be a problem because I can use a simple algorithm as proof-of-concept. As for the second idea, something like what you suggest will definitely be in the works. I'm actually a bit skeptical as to whether or not I'll see any major improvements here, but sometimes I surprise myself. In terms of other languages and their concurrency approaches, that's probably something I'll want to look at if I have time, so I'll keep it in mind. Thanks. Edit: I gave some thought to what you said about the Ada task model vs. C++ and threads, and it seems to me like different concurrency models must still be implemented at the base with C++ or assembly. I guess the question then becomes, how do you use lower-level languages to implement a higher-level concurrency model. I think what I'm essentially trying to do here is to refine a higher-level task-based model by using something like threads.

modified on Sunday, July 12, 2009 8:23 PM

Concurrency is one of those things that gets me all worked up and interested, and part of the reason for this is because I find it great fun to be creating some sort of framework that others might be able to use, in order to increase their scalability, where all they have to do is figure out which parts are scalable, and leave the gory details of handling concurrency to the framework. Anyway, I'm looking to do some research and experimentation (and write a short document on my findings) on something concurrency related on Windows. I've read some articles in the past on how to properly/efficiently use threadpools (by Herb Sutter, other concurrency gurus, and such), and one of the problems mentioned was a thread in a threadpool waiting on another thread in the threadpool, since you've effectively reduced your concurrency. I'd like to attempt to solve this problem in C++ by attempting a couple of techniques: - Using fibers to emulate explicit wait API calls (WaitForSingleObject, etc.) so that waits essentially cause a switch to a different threadpool task, until the wait is ready. The idea behind this is that we can preserve the number of threads in a threadpool, and have them switch between fibers while one is waiting on another thread, and then have them switch back to the original fiber when it's ready to run. This is because a thread can have multiple fibers. For those that don't know, a fiber can be sort of seen as a lightweight thread with its own stack space that is attached to an actual thread. Of course, feel free to correct me if I'm wrong, since I'm fairly new to this. - Optimizing a threadpool by using more threads than can be efficiently used concurrently. The idea behind this is that in a 4-core system, 4 active tasks can be performed at a time, but if one of these tasks waits on another task, then only 3 active tasks are working, so we optimize the threadpool by having for instance 6 tasks in all (4 running, 2 blocked), and when necessary to preserve maximum concurrency, we unblock the blocked tasks, and block them again where possible (I've seen allusions to the fact that we can do this, but this will require some more research). I've already crafted (in previous attempts at research and testing), my own somewhat generic C++ threadpool framework, and my idea is to add the above concepts to what I currently have, to answer a few questions at least: - Are my ideas feasible and not overly complicated? - Is it possible to generalize what I'm trying to do in a framework?

Check to see if you're not initializing any pointers to 0. Debug mode will do this for you, but in release mode, a pointer may start off with a garbage value, and consequently, if you try to use it, any one of a number of weird things can happen.

Actually, yes it is the base C# language that makes it so good for solving a wide array of problems, because quite simply, it learns a lot from previous languages as to what they didn't do right, and does it better. C++ has a lot of intricate and complex syntactical conventions that are just not clear unless you've read several books. Since I work with both tools, I have to at least take some of the time to learn what I need to learn in order to get done what needs to get done, but it's undeniable that C++ has a lot of shortcomings that have come about as we've progressed in the development of programming languages.

C# is C++, that has been made nicer. I do probably 75/25 C++/C#, but it's clear which language is more elegant in terms of syntax and conventions. What C++ needs is a complete redesign, to get rid of a lot of the stuff that doesn't work in languages, and add stuff that works. No, I don't mean C++0x which is like a little bandaid patch. Unfortunately, it has a lot of interoperability to keep, so that won't ever happen. When you say C# is slow, you should also qualify your statement. How slow and which parts are slow? It may not be as fast as native code in general, but compare it to an interpreted language like python. Then, how slow are we talking about?

I'll try this, thanks.

Yeah, well, the way I see it, malloc just does a simple memory allocation, whereas new also calls the parameterless constructor. In this case, since I'm overwriting everything, I figured malloc was the better way, but from my testing, it seems that new works as well. I've managed to get some sample code working, and it seems to be fine when T = int, but I've been told that it may not work where T is a more complicated class.

My title is probably not very well phrased, but here is the problem. Let's say I've got functions a(), b(), where a() calls b(), and b() calls vector<T>::iterator iter = someVector.begin(). b() needs to pass this iterator down to a() via a void* mechanism, without returning it (essentially using reference passing), so more explicitly, the two functions are:

void a(void*& param);
void b(void*& param);

The problem is, we can't simply do something like this:

vector<T>::iterator iter = someVector.begin();
param = reinterpret_cast<void*>(iter)

This is because the compiler (MSVC9) will complain about trying to cast an iterator to a void*:

error C2440: 'reinterpret_cast' : cannot convert from 'std::_Vector_iterator<_Ty,_Alloc>' to 'void *'

Likewise, I can't do something like...

vector<T>::iterator iter = someVector.begin();
param = reinterpret_cast<void*>(&iter)

...because even though this will compile, it will not work because begin() actually returns an iterator object and not a pointer to some memory location, so the memory address of that object will go out of scope (not sure when, but I'm guessing when you leave b()). So, because I can't do any of this, I thought that maybe I could do a memory copy of the iterator, pass it up as a void*, and then cast it back to an iterator, so something along these lines:

vector<T>::iterator iter = someVector.begin();
void* mem = malloc(sizeof(vector<T>::iterator));
//memcpy starting from &iter up to the size, into the malloc memory
param = mem;

And on the flip side, in order to decode my data, I'd do something like this:

vector<T>::iterator = reinterpret_cast<vector<T>::iterator>(param);

I'm wondering whether or not this idea of mine is feasible or will cause me many problems, or if there is a better way of doing what I'd like to do, given the limitations (can only pass by void* reference). Thanks.

I'm not using the ReadyNAS NV+, but I do use a Thecus N5200 with 5x500 GB drives in RAID 5. Generally, speaking, these NASes are pretty similar, although I believe the ReadyNAS NV+ to be a slow NAS (from what I've seen in the reviews). Back then, the Thecus N5200 was much faster and one of few competitors in the market. Now, there is also the ReadyNAS Pro, Thecus N7700/8800, and a whole slew of products from different companies like Synology, QNAP, etc.