[future|interprocess] Could futures live in shared memory and synchronize process?
Hi, I'm working on Boost.Synchro a synchronization library that try to provide generic synchronization mechanism that can be used so synchronize threads or process. As a future is a synchronization mechanism, I was wondering if futures are intrisic of mutil-threaded programs and so they live in the protected process memory or if the concept can be used in a multi-process context and have futures/promises living on shared memory. Ion, what do you think, could it be possible to use futures/promises to synchronize process? Have some one a specific use case for this? Best regards, _____________________ Vicente Juan Botet Escribá
vicente.botet wrote:
Hi,
As a future is a synchronization mechanism, I was wondering if futures are intrisic of mutil-threaded programs and so they live in the protected process memory or if the concept can be used in a multi-process context and have futures/promises living on shared memory.
I don't see why do we want to have a future in shared memory. Do you see any use case for this? A future is a handle of a concurrency unit that has spawned another concurrency unit. A future for processes would be interesting, but passing/returning values between processes is not easy and using shared memory consumes at least 1 memory page. However, I can find useful a future returning "int", just because main returns int and a process could spawn other processes and obtain futures to them (Boost.Process child is a an example of this approach). Passing objects between processes is not easy, but there are OS mechanisms that do similar things like Solaris Doors.
Best regards, _____________________ Vicente Juan Botet Escribá
Best, Ion
----- Original Message ----- From: "Ion Gaztañaga" <igaztanaga@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, February 17, 2009 5:57 PM Subject: Re: [boost] [future|interprocess] Could futures live in shared memory and synchronize process? vicente.botet wrote:
Hi,
As a future is a synchronization mechanism, I was wondering if futures are intrisic of mutil-threaded programs and so they live in the protected process memory or if the concept can be used in a multi-process context and have futures/promises living on shared memory.
I don't see why do we want to have a future in shared memory. Do you see any use case for this?
I was just requesting the same thing. Well, it could be a way to communicate a value between a producer process and a consumer process, so ... the door is open.
A future is a handle of a concurrency unit that has spawned another concurrency unit. A future for processes would be interesting, but passing/returning values between processes is not easy and using shared memory consumes at least 1 memory page.
However, I can find useful a future returning "int", just because main returns int and a process could spawn other processes and obtain futures to them (Boost.Process child is a an example of this approach).
Yes, I see but the future needed in this case will be internal to the spawning process, isnt't it?
Passing objects between processes is not easy, but there are OS mechanisms that do similar things like Solaris Doors.
I'll take a look. Thanks, Vicente
vicente.botet wrote:
However, I can find useful a future returning "int", just because main returns int and a process could spawn other processes and obtain futures to them (Boost.Process child is a an example of this approach).
Yes, I see but the future needed in this case will be internal to the spawning process, isnt't it?
Yes, ownership of thread futures can be passed to other threads but I don't see this useful/possible for processes, we could duplicate process handles, but I don't see handles could be sharable. Maybe PIDs might be placed in shared memory and futures could be made of them. Regards, Ion
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 17 February 2009, Ion Gaztañaga wrote:
vicente.botet wrote:
However, I can find useful a future returning "int", just because main returns int and a process could spawn other processes and obtain futures to them (Boost.Process child is a an example of this approach).
Yes, I see but the future needed in this case will be internal to the spawning process, isnt't it?
Yes, ownership of thread futures can be passed to other threads but I don't see this useful/possible for processes, we could duplicate process handles, but I don't see handles could be sharable. Maybe PIDs might be placed in shared memory and futures could be made of them.
If you were implementing an interprocess future that only supported POD types, wouldn't the POD object used for the future's value just sit in the shared memory? The future wouldn't need any pids. It just needs a shared_ptr, mutex, and condition, all of which are provided by interprocess, aren't they? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmcEJUACgkQ5vihyNWuA4X3KgCgluVqZR17MKiuCsAhzEK1GyZC yu8An1ieCv9cxV4BB7zjSYngjrpw+7LW =ftG1 -----END PGP SIGNATURE-----
Frank Mori Hess wrote:
If you were implementing an interprocess future that only supported POD types, wouldn't the POD object used for the future's value just sit in the shared memory? The future wouldn't need any pids. It just needs a shared_ptr, mutex, and condition, all of which are provided by interprocess, aren't they?
That was the case I was referring to. I was talking a bout shared future objects not shared data. Of course, the correct way to implement a process-future would be to share data. But could not pass the future object (which lives in the process that called spawn) to any other process, something that you can do with threads (the thread that waits for completion does not need to be the thread that created the future). And we will need to to create a shared memory that goes away when a process dies (which is not true for POSIX systems). In theory, it could be possible, but it has some rough edges. Regards, Ion
participants (3)
-
Frank Mori Hess -
Ion Gaztañaga -
vicente.botet