WO2017095364A1

WO2017095364A1 - Managing access of objects of a plurality of types

Info

Publication number: WO2017095364A1
Application number: PCT/US2015/062920
Authority: WO
Inventors: Evan R. Kirshenbaum; Susan Deborah SPENCE
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-11-30
Filing date: 2015-11-30
Publication date: 2017-06-08

Abstract

A first request is received to manage a first object associated with a first type of the plurality of types, the first request including a first access key. A second request to obtain access to an object is received, the second request including a second access key and an indication of a second type. Based on the second access key, it is determined that the second request refers to the first object. In response to determining that the second type does not match the first type, responding to the second request without providing access to the first object.

Description

MANAGING ACCESS OF OBJECTS OF A PLURALITY OF TYPES Background

[0001 ] A data store can be used to store data that is accessible by various requesters. Requesters can include an executed instance of a program, a hardware device such as a processor, and an input/output (I/O) device, or a user.

Brief Description Of The Drawings

[0002] Some implementations are described with respect to the following figures.

[0003] Fig. 1 is a block diagram of an example system that includes a data store that stores objects of different types, and a type-safe management engine according to some implementations.

[0004] Figs. 2A-2C are flow diagrams of example processes of managing access to objects associated with multiple different types, according to some

implementations.

[0005] Fig. 3 is a schematic diagram of an example hierarchy of types, according to some implementations.

[0006] Fig. 4 is a flow diagram of an example process to manage access of an object, according to some implementations.

[0007] Figs. 5 and 6 are block diagrams of example systems according to some implementations.

Detailed Description

[0008] Different types of objects can be stored in a data store. A data store can refer to a data structure that is used to store objects. An "object" can refer to any unit of data that can be stored. Examples of objects include files, directories, primitives (e.g. a number, a Boolean value, a character, etc.), and so forth. In some implementations, the data store can include a namespace that associates names with objects. An example of a namespace is a file system, in which objects are stored as files that are identified by filenames. Another example of a namespace is a key-value store, which stores associated key-value pairs. A key (an example of a name of a namespace) can be used to find a respective value stored in the key- value store. More generally, a namespace maps from names to objects. A name can be in the form of a string (of characters), or more generally, in the form of objects.

[0009] The data store can be stored in a storage device, or can be stored in a distributed arrangement of storage devices.

[0010] In some examples, a requester (e.g. an executed instance of a program, a hardware device, or a user) may be uncertain of a type of an object that is returned in response to a lookup request. The name of the object may have an extension (e.g. .doc or .mp3) or other indication that purports to indicate the type of the object. However, the object may not actually be of the type indicated by the indication in the name of the object. Thus, when the requester attempts to read or use the object, an error may result if the object is not of the type expected by the requester.

[001 1 ] In accordance with some implementations of the present disclosure, techniques or mechanisms provide type-safe management of objects in a data store. A lookup request for an object can include an indication of an expected type (that is the type sought by a requester). The system responding to the lookup request returns a representation of the object in response to determining that the object is of a type that matches the expected type, where the representation of the object includes information that facilitates interaction with the object. The representation of the object can be the object itself, a copy of the object, a proxy to the object, a reference to the object, or a pointer to the object. The reference to the object can include information that is useable to identify the object. The pointer to the object specifies a location of the object. The proxy to the object can be a different object (or a pointer or reference to such) that provides an interface which, when called, causes interaction with the object. If the object is not of the expected type indicated by the lookup request, the system does not return the representation of the object, but rather may provide an indication (e.g. a null value, an error value, a thrown exception, or other indication) that the object sought by the requester is of a type that does not match the expected type.

[0012] Fig. 1 is a block diagram of an example system 100 that includes a data store 102 to store objects 104 of multiple different types 108. The system 100 can include a computer system, or a distributed arrangement of computer systems. The data store 102 can be stored on a storage medium (or storage media) 103. In some examples, the storage medium (or storage media) 103 can be a non-volatile storage medium (or storage media), which is able to maintain stored content even when power is removed from the storage medium (or storage media) 103. For example, a non-volatile storage medium can include any or some combination of: a non-volatile memory such as phase change memory, memristor memory, spin-torque transfer memory, flash memory; a disk-based storage medium; or any other type of nonvolatile storage medium. In some examples, the storage medium (or storage media) 103 can be a volatile storage medium (or storage media), such as a dynamic random access memory (DRAM).

[0013] A "type" of an object refers to a characteristic (or set of characteristics) of the object. Examples of different types include integer, floating point number, Boolean value, character, string, user-defined type, or any other type. A user- defined type can be a type defined by a program rather than by a programming language and may be called a record, class, struct, structure, or UDT. Note that a type of an object can refer to a complex type that is a combination of other types. Certain types can be considered primitive types, such as integer, floating point number, Boolean value, character, and string. An example of a complex type can be a list or array of objects (e.g. list of employees, etc.).

[0014] The system 100 also includes a type-safe management engine 106 according to some implementations, which can manage objects 104 of different types. In some implementations, an "engine" can refer to hardware processing circuitry, including as examples a microprocessor, a core of a multi-core

microprocessor, a programmable gate array (PGA), an application specific integrated circuit (ASIC) device, and so forth. In other implementations, an "engine" can refer to a combination of hardware processing circuitry and machine-readable instructions executable on the hardware processing circuitry. In some implementations, the type- safe management engine 106 may include instructions executing concurrently within multiple operating system processes within the system 100 responsive to requests initiated by programs executing in the same multiple processes. In some

implementations, the multiple operating system processes may execute concurrently on multiple processors or multiple cores of a single processor.

[0015] Managing an object can refer to associating the object with a name, accessing the object in response to a request to obtain access the object associated with a given name, modifying the object, and/or other actions that can be performed with respect to the object.

[0016] A type-safe management of objects of different types can refer to an object management technique in which a type of an object is considered in

performing management of the object. For example, access to an object sought by a request is allowed if the object is of a type that matches an expected type indicated by the request, but access to the object is not allowed if the type of the object does not match the expected type.

[0017] Fig. 2A is a flow diagram of an example process of managing objects associated with multiple types. In some implementations, the process of Fig. 2A can be performed by the type-safe management engine 106 of Fig. 1 .

[0018] The process of Fig. 2A includes receiving (at 202), from a first requester, a first request to manage a first object associated with a first type of the multiple types, where the first request includes a first access key. The association of the first object and first type may be determinable by inspection of the first object, by the choice of function called to initiate the first request, by a type specified as a parameter to the first request, or by other means. An "access key" can refer to any information that is used to identify or locate an object that is being sought by a request. In some examples, an access key can include a name (such as a string), or a sequence of names. A sequence of names can also be referred to as a "path". In some examples, the sequence of names can be specified by providing a single character string that can be interpreted as a sequence by splitting the string into names, for example, at a specified delimiter character. In other examples, the access key can include any other information that is usable to identify or locate an object. In some examples, the request can further include a reference to or other indication of a namespace.

[0019] The process of Fig. 2A further includes receiving (at 204), from a second requester, a second request to obtain access to an object, where the second request includes a second access key and an indication of a second type. The indication of the second type included in the second request can be in the form of information that identifies the second type or information from which the second type can be derived. In some examples, the indication of the second type may be implicit in the choice of function called to initiate the second request, while in other examples the indication of the second type may be specified explicitly in the request. The second requester can be the same as the first requester. Alternatively, the second requester can be different from the first requester, such as in a multi-processing system. As

examples, the first and second requesters can include first and second program instances (e.g. first and second processes or first and second threads), or

alternatively, the first and second requesters can include first and second hardware devices or first and second users, or any combination of program instances, hardware devices, and users.

[0020] Note that the process of Fig. 2A can respond to the first and second requests by accessing the data store 102 in the storage medium (or storage media) 103, which can be non-volatile in some examples.

[0021 ] The process includes determining (at 206), based on the second access key, that the second request refers to the first object. It is noted that the second access key can be identical to the first access key, or alternatively, the second access key can be different from the first access key, but both the first and second access keys refer to the same object given the state of the data store 102 during the processing of the second request.

[0022] The process further includes determining (at 208) whether the second type indicated by the second request matches the first type of the first object. In some examples, the determination that the second type matches the first type is a determination that there is an exact match between the second type and the first type. In other examples, the determination that the second type matches the first type is a determination that the second type is compatible with the first type. The concept of compatibility is discussed further below.

[0023] In response to determining that the second type does not match the first type, the process includes responding (at 210) to the second request without providing access to the first object. Rather, an indication (e.g. a null value, an error value, a thrown exception, or some other indication) can be returned to the requester, where the indication indicates that access to the first object sought by the second request is not available. In some examples, the indication may include information about the type of the object.

[0024] As noted above, in some implementations, the type-safe management engine 106 may include instructions executing concurrently within multiple operating system processes within the system 100 responsive to requests initiated by programs executing in the same multiple processes. The instructions of the type- safe management engine 106 executing in a first operating system process can be considered a "first management engine," while the instructions of the type-safe management engine 106 executing in a second operating system process can be considered a "second management engine." The first request of Fig. 2A may be initiated by a first requester acting in a first operating system process in the system 100, and is responded to by the first management engine acting in the first operating system process. The second request of Fig. 2A may be initiated by a second requester acting in a second operating system process in the system different from the first process and is responded to by a second management engine acting in the second operating system process. With such implementations, the request from a requester acting in a given operating system process can be handled locally by the respective management engine in the given operating system process. In some implementations, the first and second management engines may operate in multiple program threads within the same operating system processes or within different operating system processes receiving requests from requesters acting in their respective program threads and handling the requests within the same program threads. It is noted that the first and second management engines can cooperate as part of the overall type-safe management of objects in a data store, where the association of an object with a respective type performed by one management engine is visible to a lookup performed by the other management engine.

[0025] Fig. 2B illustrates a further example process, which can continue from the process of Fig. 2A. The process of Fig. 2B can also be performed by the type-safe management engine 106 in some implementations. The process of Fig. 2B can include receiving (at 212), a third request to obtain access to an object, where the third request includes a third access key and an indication of a third type. The process can include determining (at 214), based on the third access key, that the third request refers to the first object. It is noted that the third access key can be identical to the first access key, or alternatively, the third access key can be different from the first access key, but both the first and third access keys refer to the same object.

[0026] The process further includes determining (at 216) whether the third type indicated by the third request matches the first type of the first object. In response to determining that the third type matches the first type, the process can include returning (at 218) information to allow access to the first object. The returned information can include a copy of the first object, a reference to the first object, a pointer to the first object, or a proxy to the first object, as examples.

[0027] Fig. 2C illustrates an additional example process, which can continue from the process of Fig. 2A. The process of Fig. 2C can also be performed by the type- safe management engine 106 in some implementations. The process of Fig. 2C can include receiving (at 220) a third request to manage a second object associated with a third type different from the first type, the third request including a third access key matching the first access key (e.g. the third access key is the same as the first access key or differing from it in irrelevant factors such as, in some implementations, whether characters are in upper or lower case). In some examples, the third request can be a request to replace, in the data store 102, the first object associated with the first type with the second object associated with the third type.

[0028] The process of Fig. 2C includes receiving (at 222) a fourth request to obtain access to an object, the fourth request including a fourth access key. The process includes determining (at 224) based on the fourth access key that the fourth request refers to the second object and not the first object. Thus, in some examples where the first object has been replaced with the second object in the data store 102, the type-safe management engine 102 is able to respond to the fourth request with information pertaining to the second object, rather than the first object.

[0029] In the ensuing discussion, it is assumed that the data store 102 presents a namespace, e.g. a mapping from names to objects 104, also called a directory, catalog, or folder. Each object 104 in the data store 102 is associated with a type. For some objects 104, their associated types 108 can also be stored in the data store 102. These associated types 108 can be used by the system 100 to determine the type of the respective objects 104. For other objects 104, such as primitive objects (e.g. a number, a Boolean value, a character, etc.), the respective types may not be stored in the data store 102. However, the system 102 may be able to recognize the type of such objects 104 based on characteristics of the objects 104.

[0030] In some implementations, a namespace can be a hierarchical

namespace. A hierarchical namespace is one in which the value associated by the namespace with a name may be another namespace. For example, a file system can have a hierarchy of directories and files. A hierarchical namespace may have one or more root (or global or top-level) namespaces, which may be accessible to programs via function calls. The root of the hierarchical name space can be found by calling a root() method on a Namespace class, for example. When interacting with a hierarchical namespace, the access key may be a path (also referred to as a "hierarchical name"), which may be a sequence of strings (also referred to as "simple names" or "elements"), where each element may represent a name within a namespace. A namespace may be extended by a path by looking up the elements in the path in the namespace and then subsequent namespaces encountered. If the namespace may not be extended because an element is encountered which is not bound to a value in the namespace being searched, a new namespace may be created and bound to that element. If the namespace may not be extended because an element (other than a final element) is encountered which is bound to a value other than a namespace, an error may be signaled (e.g. by throwing an exception).

[0031 ] The last element of the path may be called the final element. The sequence of elements in the path up to but not including a final element may be called the "prefix" of the path. Extending a namespace by the prefix of a path may be expected to result in the identification of a namespace. A path can be specified by a path string, which can be a string with a separator character (e.g., 7") separating elements of the path. A path can also be a specified by sequence of strings, which can either be elements or path strings. A path may be an absolute path or a relative path. When specified by a path string, a path may be an absolute path if it begins with a separator character and a relative path otherwise. When a namespace is extended by an absolute path, the namespace may be ignored and a root namespace may be substituted. In some examples, a given namespace may appear multiple times in the namespace hierarchy. It may occur as the value associated with multiple names in the same namespace, and it may occur as a value bound to names in multiple namespaces. In some examples, the namespace hierarchy may be constrained to be acyclic. In further examples, the namespace hierarchy can be in the form of a tree, with a single root and each namespace occurring once. In some examples, the namespace hierarchy can be in the form of a directed acyclic graph (DAG), with one or more roots and each namespace occurring one or more times, but with no cycles. In other examples, the namespace hierarchy can be according to other structures. [0032] In a hierarchical namespace, the access keys discussed above in connection with the example processes of Figs. 2A and 2B can be in the form of hierarchical names. As described above, a hierarchical name can be decomposable as containing a prefix and a final element. The prefix of a hierarchical name can include information that is used to find a namespace, while a final element (e.g. a string) can include information to identify an object within the namespace identified by the prefix. For example, assume a path string of the form 7a/b/c/d/e" (which includes strings separated by the separator characters 7"), then the prefix in this example is the path specified by 7a/b/c/d," which identifies a given namespace, and the final element is "e", which identifies an object in the given namespace.

[0033] In examples where an access key is in the form of a hierarchical name including a prefix and a final element, the determination (e.g. the determination at 206 in Fig. 2A or at 214 in Fig. 2B or at 224 in Fig. 2C) that an access key included in a request refers to a particular object is performed in the following manner. For example, in the process of Fig. 2A, the first access key (of the first request received at 202) is a first hierarchical name including a first prefix and a first final element, and the second access key (of the second request received at 204) is a second hierarchical name including a second prefix and a second final element. To determine (at 206), based on the second access key, that the second request refers to the first object, the type-safe management engine 106 can identify a first namespace associated with the first prefix, identify a second namespace associated with the second prefix, determine that the first namespace is the second namespace, and determine that the second final element matches the first final element. The second final element may match the first final element if the first and second final elements are equal. In some implementations, the second final element may match the first final element even though they are not equal if they are considered to be sufficiently similar. For example, the element "name" may be considered to match the element "NAME" if the system does not consider character case to be significant. Other notions of non-identical match may include considering accented and non- accented characters to match, ignoring some or all whitespace characters when matching, considering names specified "First Last" to match names specified "Last, First", and considering days specified in different languages (e.g. English "Monday" and Spanish "lunes") to match. Further notions of non-identical match are also contemplated. The same rules for non-identical matching may be considered when using the prefix of a hierarchical name to identify a namespace.

[0034] In further examples, the second request can also include an indication of a namespace, in addition to including the second access key. In such examples, the identification of the second namespace can further be based on the namespace indicated by the second request and based on the second access key. For example, the second namespace may identified by extending the namespace indicated by the second request by the hierarchical name specified as the second access key as described above.

[0035] In some implementations, the multiple types can also have a hierarchical arrangement, where types can be related to one another within a hierarchy (e.g. a first type can be a parent or child of a second type in the hierarchy). Fig. 3 shows a simple example hierarchy 300 of types, including the following types: EMPLOYEE, MANAGER, and ENGINEER. Thus, an object can be of type EMPLOYEE, type MANAGER, or type ENGINEER in this example. The hierarchy 300 of types can be stored in a storage medium (not shown in Fig. 3) and is accessible by the type-safe management engine 106 according to some implementations.

[0036] As noted above, a determination that type A matches type B is a determination that type A matches type B exactly (i.e. type A is the same as type B), or that type A is compatible with type B. In some implementations, compatibility of two types can be determined by the type-safe management engine 106 using a hierarchy of types, such as that depicted in Fig. 3. Assume that type A and type B are members of a hierarchy of types. Type A is determined to be compatible with type B, in response to type A having a specified hierarchical relationship to type B. This specified hierarchical relationship can be a dominance relationship. Thus, type A is determined to be compatible with type B, in response to type A dominating type B, where type A dominates type B when type A is a parent of type B in the hierarchy or when type A dominates some type C in the hierarchy and type C dominates type B. In Fig. 3, the EMPLOYEE type dominates each of the MANAGER type and the ENGINEER type, which means that any object of the MANAGER type is also an object of the EMPLOYEE type, and similarly, any object of the ENGINEER type is also an object of the EMPLOYEE type.

[0037] As an example, assume that an object stored in the data store 102 is associated with the ENGINEER type. A request to obtain access to this object can include an access key that refers to the object, and can include an indication of the ENGINEER type. In this case, the system can respond to the request by returning information to allow access of the object of the ENGINEER type.

[0038] As an alternative example, the request can include an indication of the EMPLOYEE type. In this case, the system can determine that the EMPLOYEE type dominates the ENGINEER type, and thus the EMPLOYEE type is compatible with the ENGINEER type. In this case, the system can respond to the request by returning information to allow access of the object as an object of the EMPLOYEE type.

[0039] As a further alternative example, the request can include an indication of the MANAGER type. In this case, the MANAGER type is incompatible with the ENGINEER type (i.e. they do not match), and as a result, the system can respond to the request by not providing access to the object.

[0040] In other examples, instead of determining compatibility between types based on hierarchical relationships between types, other forms of computability tests can be employed. For example, another compatibility test can include a

determination of whether a mechanism exists that allows for an object of type A to be used as an object of type B. Such a mechanism can include the creation or identification of an adapter object or proxy object that can be used as an object of type B and which, when so used, makes reference to the object of type A, allowing an object of type A to be used as an object of type B [0041 ] As noted above, the type-safe management engine 106 is able to associate objects with access keys (e.g. hierarchical names). In some examples, such associations can be performed by using a bind function. For example, the first request to manage a first object received at 202 in Fig. 2A or the third request to manage a second object received at 220 in Fig. 2C can include a bind function. For example, given a namespace, a name, a path, and an object, any of the following bind functions can be invoked to bind the object identified by object with a path identified by path or with name within namespace:

(1 ) object. bindName(namespace, name);

(2) object. bindName(path);

(3) namespace. bind(name, object);

(4) path.bind(object).

[0042] Note that other example bind functions can be used in other examples. Note that in bind functions (3) and (4) above, object can identify a primitive object.

[0043] The same object can be bound to multiple names in the same namespace or in different namespaces.

[0044] To obtain an object bound to a name, a request can include an indication of an expected type (the type expected by the requester). As examples, the following lookup functions can be employed:

(1 ) type.lookupName(namespace, name);

(2) type.lookupName(path);

(3) namespace.lookup(name, type);

(4) path.lookup(type).

[0045] Note that other example lookup functions can be used in other examples. Note another lookup function, e.g. path.lookupBooleanQ, can be used for primitive objects and can specify the expected type (e.g. a Boolean value) implicitly. The second request (received at 204 in Fig. 2A), the third request (received at 212 in Fig. 2B), and/or the fourth request (received at 222 in Fig. 2C) can include any of the foregoing lookup functions. Each of the lookup functions can return a reference to the object bound to the indicated path (e.g. path or combination of namespace and name), but only if the type of that object is compatible with the expected type.

[0046] If a path included in a lookup function is not bound to an object, an exception indicating an unbound name can be thrown, or some other action can be performed. If the path itself cannot be resolved, an exception indicating that the path is not a namespace can be thrown.

[0047] In further examples, various functions can be employed to ask about a binding:

(1 ) path.isBoundQ, which asks path is bound to any object;

(2) path.isBoundTo(object), which asks \† path is bound to an object

referenced by object;

(3) path.isBoundToType(type) which asks if path is bound to any object associated with a type indicated by type;

(4) namespace.isBound(name), which asks if a path represented by

namespace and name is bound to any object;

(5) namespace. isBoundTo(object, name), which asks if a path represented by namespace and name is bound to an object referenced by object;

(6) namespace. isBoundToType(type, name), which asks if a path represented by namespace and name is bound to any object associated with a type indicated by type.

[0048] The foregoing isBound functions are used to ask various questions about bindings of objects. [0049] The type-safe management engine 106 according to some

implementations also supports a notion of "prior expectation," or more simply "prior." A prior is an object that represents a belief about a state of some entity. In the ensuing discussion, a prior is also referred to as a "guard condition." A guard condition can be added as an argument to either an isBound function or bind function, including any of the isBound functions and bind functions listed further above.

[0050] If a guard condition is added to an isBound function, the call of the isBound function returns true and provides a response regarding a binding if the guard condition is satisfied. If a guard condition is added to a bind function, the binding is performed by the bind function only if the guard condition is satisfied.

[0051 ] Several example guard conditions are listed below (note that other guard conditions can be used in other examples):

(1 ) was-unbound: true if the path was previously unbound; (2) was-bound: true if the path was previously bound to any object; (3) was-namespace: true if the path referred to a namespace;

(4) was(object): true if the path was bound to the given object identified by object.

(5) was-of-type(type) true if the path was bound to an object of type compatible with the given type identified by type.

(6) was-any always true (this guard condition may be useful in

situations in which a guard condition has to be supplied, but the requester does not really care that any guard condition has to be satisfied).

[0052] The type-safe management engine 106 may guarantee that in a call of a bind function, for the binding to succeed (e.g. for the new binding to take place), the verification of the guard condition and the modification of the binding are a single atomic action from the point of view of any other requester in the system. That is, the type-safe management engine 106 may guarantee that it is not possible to change the binding to render the guard condition false after the type-safe

management engine 106 has verified that the guard condition is true and before the type-safe management engine 106 updates the binding to the new value.

[0053] If the guard condition is false in a call of a bind function, an exception can be provided indication that the guard condition is not satisfied. This exception may hold an indication of whether the path was previously bound, whether the path referred to a namespace, and what a prior value was.

[0054] Fig. 4 is a flow diagram of an example process that uses a guard condition according to some implementations. The process of Fig. 4 can be performed by the type-safe management engine 106 in some examples.

[0055] The process of Fig. 4 includes receiving (at 402) a request to manage an object, where the request includes a guard condition. The process includes determining (at 404) whether the guard condition is satisfied. The process includes, in response to the request, returning (at 406) without managing the object if the guard condition is not satisfied.

[0056] In further examples, guard conditions can facilitate the implementation of other operations. In a specific example, the pseudocode below provides an example of how a guard condition according to some implementations can be used to implement an atomic compare-and-swap operation. Generally, a compare-and-swap operation is used in a multi-processing system (that has multiple requesters, such as program instances) to achieve synchronization. The compare-and-swap operation compares the content of a memory location to a given value and, only if the content of the memory location is the same as the given value, modifies the content of the memory location to a new value. ManagedObject expected = e;

while (true) {

try {

path.bind(compute(e), Prior.was(e));

break;

} catch (PriorExpectation Exception ex) {

e = ex.priorValue();

}

[0057] In the pseudocode above, the guard condition is expressed as

"Prior.was(e)." The instruction path.bind(compute(e), Prior.was(e)) above binds a path to a new value of an object e, where the new value of the object is generated by compute(e), in response to Prior.was(e) returning true— in other words, the path was previously bound to the previous value of the object e.

[0058] If Prior.was(e) returns false, the an exception is provided with the instruction catch (PriorExpectationException ex). The instruction e = ex.priorValue() maintains the object at the prior value of the object e.

[0059] In some examples, a namespace may be implemented by data structures contained within the storage medium 103 (Fig. 1 ) and accessed by the type-safe management engine 106. The data structures used to implement a namespace may include a map data structure, such as an unordered map, an ordered map, a hash table, a hash map, or a cuckoo hash map. This map data structure may be used to associate names with binding objects. The binding object or a reference to the binding object may contain an indication of whether the namespace considers a given name to be unbound (i.e. not bound to any object), bound to an object, or bound to a namespace. The binding object may also contain or otherwise facilitate the identification of an object or namespace to which the name is bound. When the name is bound to an object, the binding object may further contain or facilitate the identification of a type associated with the object. To guarantee atomicity of certain operations, as described above, in some examples, the type-safe management engine 106 may make use of one or more locks (also known as mutexes) associated with the namespace. In other examples, the map may be a lock-free map such as the lock-free cuckoo hash map described in PCT Application No.

PCT/US2015/062824, entitled "Providing a Segmented Hash Map," filed November 27, 2015, which is incorporated by reference in its entirety.

[0060] Fig. 5 is a block diagram of a system 500 that includes a non-transitory machine-readable or computer-readable storage medium (or storage media) 502, which can store machine-readable instructions. The machine-readable instructions can include type-safe management instructions 504 that upon execution cause the system 500 to perform various tasks, including those that can be performed by the type-safe management engine 106 discussed above. For example, the type-safe management instructions 504 can perform the example processes of Figs. 2A-2C and 4, as well as any other tasks.

[0061 ] For example, the type-safe management instructions 504 can associate objects in a data store with respective types, and in response to a request including an access key and an indication of an expected type, the type-safe management instructions 504 return a representation of an object corresponding to the access key in response to a type of the object matching the expected type, and not return the representation of the object in response to the type of the object not matching the expected type. The type-safe management instructions 504 can also perform other tasks as discussed above, such as the example processes of Figs. 2A-2C and 4

[0062] Fig. 6 is a block diagram of an example system 600 according to some implementations. The system 600 includes a data store 602 (similar to the data store 102 of Fig. 1 ) to store objects associated with respective types of multiple different types. The system 600 also includes a processor (or multiple processors) 604). A processor can include a microprocessor, a core of a multi-core

microprocessor, a microcontroller, a programmable integrated circuit, a

programmable gate array, or other processing hardware. [0063] In addition, the system 600 includes a non-transitory machine-readable storage medium (or storage media) 606 storing type-safe management instructions 608 executable on the processor(s) 604 to receive a lookup request for an object and that specifies an expected type of the plurality of different types, in response to the lookup request, return a representation of the object responsive to the object being of a type that matches the expected type, and respond to the lookup request without returning the representation of the object responsive to the object being of a type that that does not match the expected type.

[0064] The type-safe management instructions 608 can also perform other tasks as discussed above, such as the example processes of Figs. 2A-2C and 4.

[0065] Data and instructions are stored in respective storage devices, which are implemented as one or multiple computer-readable or machine-readable storage media. The storage media include different forms of memory including

semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs); nonvolatile random access memories such as memristor memories, spin-transfer torque memories, and and flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic media including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. Note that the instructions discussed above can be provided on one computer- readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple components. The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution. [0066] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.

Claims

What is claimed is 1 . A method of a system comprising a processor for managing access to objects associated with a plurality of types, comprising:

receiving a first request to manage a first object associated with a first type of the plurality of types, the first request including a first access key;

receiving a second request to obtain access to an object, the second request including a second access key and an indication of a second type;

determining, based on the second access key, that the second request refers to the first object;

determining whether the second type matches the first type; and

in response to determining that the second type does not match the first type, responding to the second request without providing access to the first object.

2. The method of claim 1 , further comprising:

receiving a third request to obtain access to an object, the third request including a third access key and an indication of a third type;

determining, based on the third access key, that the third request refers to the first object;

determining whether the third type matches the first type;

in response to determining that the third type matches the first type, returning information to allow access to the first object.

3. The method of claim 2, wherein the information is one selected from among a reference to the first object, a pointer to the first object, or a copy of the first object.

4. The method of claim 2, wherein the first type and the third type are members of a hierarchy of types, and wherein the third type is determined to match the first type responsive to:

the third type being the first type, or

the third type dominating the first type within the hierarchy, and

wherein the returned information allows access to the first object as an object of the third type.

5. The method of claim 1 , wherein the first access key is a first hierarchical name containing a first prefix and a first final element, and the second access key is a second hierarchical name containing a second prefix and a second final element.

6. The method of claim 5, further comprising:

in response to the first request, identifying a first namespace associated with the first prefix,

wherein determining that the second request refers to the first object comprises:

identifying a second namespace associated with the second prefix;

determining that the first namespace is the second namespace; and determining that the second final element matches the first final element.

7. The method of claim 6, wherein the second request further includes an indication of a third namespace, and wherein identifying the second namespace comprises identifying a namespace based on the third namespace and the second access key.

8. The method of claim 1 , further comprising:

receiving a third request to manage a second object associated with a third type different from the first type, the third request including a third access key matching the first access key;

receiving a fourth request to obtain access to an object, the fourth request including a fourth access key; and

determining based on the fourth access key that the fourth request refers to the second object and not the first object.

9. The method of claim 1 , wherein the first request is initiated by a first requester acting in a first process in the system and is responded to by a first management engine acting in the first process, and wherein the second request is initiated by a second requester acting in a second process in the system different from the first process and is responded to by a second management engine acting in the second process.

10. The method of claim 1 , wherein responding to each of the first and second requests comprises accessing a non-volatile storage.

1 1 . The method of claim 1 , further comprising:

receiving a third request to manage a second object, the third request including a guard condition;

determining whether the guard condition is satisfied; and

in response to the third request, returning without managing the second object if the guard condition is not satisfied.

12. An article comprising at least one non-transitory machine-readable storage medium storing instructions that upon execution cause a system to:

associate objects in a data store with respective types; and

in response to a request including an access key and an indication of an expected type,

return a representation of an object corresponding to the access key in response to a type of the object matching the expected type, and

not return the representation of the object in response to the type of the object not matching the expected type.

13. The article of claim 12, wherein the type of the object matches the expected type responsive to the type of the object and the expected type being the same.

14. The article of claim 12, wherein the type of the object matches the expected type responsive to the type of the object and the expected type being comptable.

15. A system comprising:

a data store to store objects associated with respective types of a plurality of different types;

a processor; and

a non-transitory machine-readable storage medium storing instructions executable on the processor to:

receive a lookup request for an object and that specifies an expected type of the plurality of different types;

in response to the lookup request, return a representation of the object responsive to the object being of a type that matches the expected type; and

respond to the lookup request without returning the representation of the object responsive to the object being of a type that that does not match the expected type.