U++ forum: Welcome to the forum

Search on this site

Search in forums

Home » U++ Library support » U++ Core » CoWork and shared memory

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

CoWork and shared memory [message #35489]

Wed, 22 February 2012 17:53

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

Report message to a moderator

Re: CoWork and shared memory [message #35498 is a reply to message #35489]

Thu, 23 February 2012 20:38

mirek
Messages: 14271
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

Report message to a moderator

Re: CoWork and shared memory [message #35503 is a reply to message #35498]

Thu, 23 February 2012 21:41

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

Report message to a moderator

Re: CoWork and shared memory [message #35508 is a reply to message #35503]

Fri, 24 February 2012 11:53

mirek
Messages: 14271
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.

Report message to a moderator

Re: CoWork and shared memory [message #35509 is a reply to message #35508]

Fri, 24 February 2012 11:56

mirek
Messages: 14271
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.

Report message to a moderator

Re: CoWork and shared memory [message #35510 is a reply to message #35509]

Fri, 24 February 2012 13:04

peek
Messages: 13
Registered: March 2010

Promising Member

Great

, 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?.

Report message to a moderator

Re: CoWork and shared memory [message #35512 is a reply to message #35510]

Fri, 24 February 2012 13:52

mirek
Messages: 14271
Registered: November 2005

Ultimate Member

peek wrote on Fri, 24 February 2012 07:04

Great

, 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.

Report message to a moderator

Re: CoWork and shared memory [message #35528 is a reply to message #35512]

Sat, 25 February 2012 20:05

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

Report message to a moderator

Re: CoWork and shared memory [message #35530 is a reply to message #35528]

Sun, 26 February 2012 09:56

mirek
Messages: 14271
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

Report message to a moderator

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

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sun Oct 26 11:46:26 CET 2025

Total time taken to generate the page: 0.03697 seconds