Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Core » CoWork and shared memory
CoWork and shared memory [message #35489] Wed, 22 February 2012 17:53 Go to next message
peek is currently offline  peek
Messages: 13
Registered: March 2010
Promising Member
Hello all

Is it possible that processes running in different cores with CoWork can share the same memory through a mutex?

Peek
Re: CoWork and shared memory [message #35498 is a reply to message #35489] Thu, 23 February 2012 20:38 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
peek wrote on Wed, 22 February 2012 11:53

Hello all

Is it possible that processes running in different cores with CoWork can share the same memory through a mutex?

Peek


Sure. Is there any reason why it shlould not?

Mirek
Re: CoWork and shared memory [message #35503 is a reply to message #35498] Thu, 23 February 2012 21:41 Go to previous messageGo to next message
peek is currently offline  peek
Messages: 13
Registered: March 2010
Promising Member
Thank you Mirek

I will try with some INITBLOCK.

The reason of the question was that in the doc it says:

Quote:

This class is indented as loop-parallelization tool. Whenever loop iterations are independent (they do not share any data)


Thank you again Smile
Re: CoWork and shared memory [message #35508 is a reply to message #35503] Fri, 24 February 2012 11:53 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
peek wrote on Thu, 23 February 2012 15:41

Thank you Mirek

I will try with some INITBLOCK.

The reason of the question was that in the doc it says:

Quote:

This class is indented as loop-parallelization tool. Whenever loop iterations are independent (they do not share any data)


Thank you again Smile


Ah, sorry, I guess it would need more clarification. The real deal is that 'not share any data' is best wrt performance.
Re: CoWork and shared memory [message #35509 is a reply to message #35508] Fri, 24 February 2012 11:56 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Like this:

Whenever loop iterations are independent (they do not share any data between iterations), CoWork can be used to relatively easily spawn loop iterations over thread and thus over CPU cores. Note that previous statement does not preclude CoWork iterations to share data at all - sharing data using Mutex or similar serialization mechanisms still works.
Re: CoWork and shared memory [message #35510 is a reply to message #35509] Fri, 24 February 2012 13:04 Go to previous messageGo to next message
peek is currently offline  peek
Messages: 13
Registered: March 2010
Promising Member
Great Smile, I understand.

One question: This way it would be better to use CoWork instead of Thread because CoWork always tries to run in all available cores but Thread only runs in actual core?.
Re: CoWork and shared memory [message #35512 is a reply to message #35510] Fri, 24 February 2012 13:52 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
peek wrote on Fri, 24 February 2012 07:04

Great Smile, I understand.

One question: This way it would be better to use CoWork instead of Thread because CoWork always tries to run in all available cores but Thread only runs in actual core?.


Ah, the answer is a bit more complicated. CoWork actually uses thread pool - it creates a couple of threads (number of logical CPU cores + 2) the first time it is used and then uses all these threads to execute everything in parallel. So you are at least saved thread creation/destruction costs. Plus, it uses the very same pool for any nested looping (you can use another CoWork loop nested with within). Actually, it does not even have to be a loop, simply what you run with CoWork will possibly run in parallel and you can be sure that at CoWork destructor, all is finished. The order of running those tasks is of course unspecified.
Re: CoWork and shared memory [message #35528 is a reply to message #35512] Sat, 25 February 2012 20:05 Go to previous messageGo to next message
peek is currently offline  peek
Messages: 13
Registered: March 2010
Promising Member
Hello Mirek

So this way have Cowork processes to end fast because they work in any way in the same thread that main program?

I mean, to do:
App::~App() {
	finish = true;
	...

// and in Cowork function
if (finish)
	return;

is useless as destructor is not accessible until Cowork variable is destructed and that is is done when all Cowork calls have ended.

A question: If the Cowork jobs lasts time a solution could be to run Cowork in a separate thread?

Peek
Re: CoWork and shared memory [message #35530 is a reply to message #35528] Sun, 26 February 2012 09:56 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
peek wrote on Sat, 25 February 2012 14:05

Hello Mirek

So this way have Cowork processes to end fast because they work in any way in the same thread that main program?

I mean, to do:
App::~App() {
	finish = true;
	...

// and in Cowork function
if (finish)
	return;

is useless as destructor is not accessible until Cowork variable is destructed and that is is done when all Cowork calls have ended.



No, this still works - CoWork has no clue what the processing is and this one simply makes the processing "nop" and it ends quickly. The loop would still go through all iterations, thread will still preform them, but each iteration job will end immediately...

Quote:


A question: If the Cowork jobs lasts time a solution could be to run Cowork in a separate thread?



Well, not really, if you want a clean exit from the app...

The problematic thing is that for clean exit, you need cannot use any form on thread abortion - it has to exit through its normal exit point; otherwise it would result in resource leaks.

Mirek
Previous Topic: Point implicit conversions
Next Topic: put32 for double precision values..
Goto Forum:
  


Current Time: Fri Mar 29 11:39:11 CET 2024

Total time taken to generate the page: 0.01868 seconds