Fast and Best Producer/consumer queue technique BlockingCollection vs concurrent Queue [closed] - concurrency

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Im using Generic.Queue in C# 3.0 and Monitor.Enter,wait,exit for wait before consuming the queue (wait for the element to be enqueued). Now im moving to C# 4.
Can anyone suggest me which one is fast and best especially to avoid locks..
BlockingCollection vs concurrentQueue or any thing else...
Note. I dont want to restrict my producer
Thanks in advance..

BlockingCollection and ConcurrentQueue are there for precisely this reason. I doubt that you'll find anything better, or simpler to use. The parallel extensions team know their stuff :)
Just a quick check on versions though - you're definitely using .NET 4, not just C# 4? (For example, you could be using Visual Studio 2010 and thus C# 4, but still targeting .NET 3.5, in which case you couldn't use Parallel Extensions.)
You may also want to start researching Task-Based Asynchronous Pattern, TPL Dataflow and the async/await features of C# 5... obviously you can't use them just yet, but it doesn't hurt to know what's coming up.

Related

Thread Loop with Sleep() or SetTimer [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have an Win32 app that contains 13 SetTimer() calls... I have a doubt: to optimize application performance, would be better to use CreateThread (with infinite loop and Sleep) instead SetTimer? Which of the two ways to a better way and timing of actions?
Sorry for bad english, thanks in advance!
I wouldn't write a custom timer unless you have a very specific need to do so. I'd guess performance difference would be negligible for most applications. Plus you'll run into other issues I'm sure you're not currently considering, like data synchronization, communicating with your GUI thread for user interactions, etc. It's possible you could even make performance worse.
If you feel you have a specific need, state what that need is and maybe we can guide the answer.

What are my options for cross program communication? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
A while ago i made a database framework in c++ and have been using it in various places, even made a wrapper for it for vb.net.
Now i have a new project that would require multiple programs accessing a single database and it would be wasteful to load up the database multiple times for every one of them not to mention the syncing horrors.
So I figured i would turn the framework into a standalone application and access to the data would be done in some xx magical way from those other programs. From what I've seen php and mysql do something like this..?
Problem is, I have no clue where to start. The only kind of cross program communication i've done is one program reading and writing directly into the other ones memory, seems kinda hacky though and I'm not sure if that sort of thing is going to fly with managed languages (I want to make it accessible in vb.net too).
Tips?
The most portable way to do IPC (inter-process communication) is probably going to be Sockets.
What about D-Bus? There ist a port for Windows.

Do I still need multithreading or is it obsolete? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm just working myself into the boost libraries and there's one question that stucks in my head :D
Is multithreading, especially the boost one and for game development, still used? I understand the pros of threading but I'm not sure if it's not obsolete. If not, where does it get used in game development?
RenX
Yes, you're still need it. No, it is not obsolete. Moreover, multi-thread support is the one of the most progressive and integral parts of the modern game development. Almost every modern game engine has multi-thread support. Why? Because animation and the physics; rendering and resource loading could performs simultaneously, and even physics itself may be parallellized, this also applies to the paging. What about boost, Ogre3D uses boost::threads for multi-threaded purposes (if you're an enthusiast, you should be familliar with Ogre3D, aren't you?). Unreal Engine 3 uses the rendering thread and the game-logic thread, separated from the main application's thread, moreover, UE 3.5 has Unreal Swarm as the job distribution system and Gemini as ultra-fast HDR rendering pipeline. So yes, it has sense.

boost vs POCO as for learning curve and suitability for beginners (HTTP client) [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
which library would you advise me to use? I don't know any of these libraries.
I heard, that Boost is very often used but also it's hard to code in.
So to make this question as objective as possible:
Just simply from the aspect of beginner programmer (I've coded ~1000 LOC in C++ in my life)
which library would be better to learn?
I'll be using it mainly for HTTP client.
The answer is bound to be subjective but with particular emphasis on for a beginner then I think POCO is clearly the way to go. It actually has some HTTPClient classes and once you get beyond the point of being happy that something works the code is clear enough to follow so that you can dig in and understand why it works if that is where things lead you.
POCO is well written OOP code and does not require much in the way of understanding templates and such. The classes are well integrated with one another, extensive, and the documentation more or less points you to the next (or previous) class that you need. You won't be dashing around 20 separate libs as Boost is likely to have you doing. (There is always time for that later!)

libstdc++ parallel mode: Who's using it? Is it safe? Any similar projects? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
the GNU implementation of the C++ Library supports a parallel mode, explained here.
Any experiences in using it? Good ones? Bad ones? Especially regarding correctness, but also performance.
Are there some "more or less serious" projects using it?
Do you use it with the global turn-on-parallel switch -D_GLIBCXX_PARALLEL or do you use it carefully with manually turn-on specific parallelization functions like: __gnu_parallel::sort(v.begin(), v.end());?
Are there any similar open source projects? Meaning: more easy parallelization than using openMP.
Thanks for your experiences.
Sascha
Too late answer, but:
I would seriously consider Intel TBB. One thing that I noted missing from C++ standard parallel mode is parallel containers. TBB containers do not follow the interface of C++ standard containers, but they provide justifications for this. Besides, TBB has a number of examples and design patterns.
I've used it for some small projects, with a nice speedup for large stl operations. I never encountered any problems (I used the global switch). However I didn't really do much benchmarking, you might want to refer to studies like http://algo2.iti.kit.edu/singler/mcstl/parallelmode_se.pdf and http://ls11-www.cs.uni-dortmund.de/people/gutweng/AD08/VO11_parallel_mode_overview.pdf.
This seems similar though I haven't looked very deeply into it. http://thrust.github.com/