Send hpx-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hpx-devel digest..."
Today's Topics:
1. Re: id_type should go (Thomas Heller)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Sep 2015 16:46:40 +0200
From: Thomas Heller <[email protected]>
Subject: Re: [hpx-devel] id_type should go
To: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
I further pursued this topic and implemented a first type version for a GID:
hpx::naming::locality
It is a simple, unmanaged GID, which is a executor, as such, no
additional interface changes were necessary and it can be used
seamlessly with apply and async.
An example testcase can be found here:
https://github.com/STEllAR-GROUP/hpx/blob/remove_id_type/tests/unit/naming/locality.cpp
In addition, I changed the interface of new_ (still fully backwards
compatible with passing an id_type as the locality GID) to take this new
GID representation.
See the testcase here:
https://github.com/STEllAR-GROUP/hpx/blob/remove_id_type/tests/unit/component/new_.cpp
The implementation is actually pretty simple:
https://github.com/STEllAR-GROUP/hpx/blob/remove_id_type/hpx/runtime/naming/locality.hpp
I think this is a great addition to a more type safe interface!
If you like the idea, I would like to implement three more type safe GIDs:
- unique_id<Component>:
* Keeps the Component alive as long as the instance is alive, carries
an initial amount of credit, there is only one owner for that component.
* Is an executor
- managed_id<Component> (maybe better: shared_id<Component>):
* multiple instances of this class can exist, and will hold the
component alive until the last one will go out of scope (similar to
std::shared_ptr)
* A unique_id can be converted to a managed_id (same as unique_ptr ->
shared_ptr)
* Is an executor
- unmanaged_id<Component> (maybe better: weak_id<Componend>):
* A weak reference to a component, does not hold the component alive
(similar to std::weak_ptr)
* ownership can be obtained by calling .lock() (or similar) returning
a managed_id<Component>
* Not an executor
What do you guys think? I'd like to continuously adapt our API to use
those kind of classes.
Cheers,
Thomas
On 07/07/2015 04:10 PM, Thomas Heller wrote:
> Dear all,
>
> Over the last couple of weeks I've been stating on IRC that id_type
> should go. I would like to summarize my ideas and problems I see with it
> here and suggest a possible way forward to improve our general API.
>
> First of all, using plain id_type objects has several semantics attached
> which I see as problematic and not necessarily transparent or obvious
> when they are being used. The problems I see are:
> - An id_type can be both managed or unmanaged which changes the
> semantic of the global reference counting scheme but is not
> transparently visible to users of id_type, that is, intent of ownership
> can not be cleanly expressed.
> - An id_type is not type safe at compile time, it's very easy to pass
> an id_type to async or another API function that leads to a type
> mismatch at runtime. Furthermore, it is not always obvious from a
> signature of a function what kind of id_type that function expects.
>
> As far as the semantic of an id_type is concerned, I always see them as
> some kind of pointer to an object in the global address space with some
> ownership semantic. The logical conclusion for me is to create a certain
> set of types that represent different ownership semantics. I am not
> particularly attached to any naming scheme, however, I would like to
> suggest the following:
> - global_unique_ptr<Component>: This is a reference to an object in the
> global address space. It should have similar semantics than unique_ptr
> in that it keeps the component alive as long as the object stays in
> scope. Ownership can be transferred through move semantics. This should
> be the default return type for API functions like new_.
> - global_ptr<Component>: This is reference to an object in the global
> address space with shared ownership semantics (similar to what a managed
> id_type is today), similar to shared_ptr. A global_ptr<Component> has a
> constructor taking ownership from a global_unique_ptr<Component>.
> - global_weak_ptr<Component>: This is a unmanaged reference to a global
> object, similar to what an unmanaged id_type is today, following the
> principle ideas of weak_ptr.
>
> Furthermore, it would make sense to introduce other 'global reference'
> classes like locality, which is unmanaged in nature but isn't tied to a
> component.
>
> All of the above should take care of both, the type safety in client
> code and clear intent of ownership.
>
> In addition, these constructs are 'futurized' in the sense that they act
> like a future (similar to client_base today).
>
> To not let our API like async, apply etc. have an unmanagable amount of
> overloads, the (possibly) remote procedure calls could be handled by
> making those pointer types executors. By specializing executor_traits we
> can reuse what is already in place today.
> This will also allow to extend our set of "global" reference types at wish.
>
> What do you think? Comments and/or suggestions?
>
> Best regards,
> Thomas
--
Thomas Heller
Friedrich-Alexander-Universit?t Erlangen-N?rnberg
Department Informatik - Lehrstuhl Rechnerarchitektur
Martensstr. 3
91058 Erlangen
Tel.: 09131/85-27018
Fax: 09131/85-27912
Email: [email protected]
------------------------------
_______________________________________________
hpx-devel mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
End of hpx-devel Digest, Vol 24, Issue 2
****************************************
