Method and system for linear tasking among a plurality of processing units

• US 7,712,111 B2
• Filed: 06/08/2005
• Issued: 05/04/2010
• Est. Priority Date: 06/08/2004
• Status: Expired due to Fees

• Current Assignee: David E. Kahn
• Original Assignee: Covia Labs, Inc.
• Inventors: Bernstein, Bruce, Mirabella, Richard, Pieb, Wolfgang, Illowsky, Daniel, Wenocur, Michael, Tiberi, Richard, Sidney, Raymond
• Primary Examiner(s): Sough; Hyung S
• Assistant Examiner(s): Anya; Charles E
• Application Number:
  US11/149,086
• Publication Number:
  US 20060206882A1
• Time in Patent Office: 1,791 Days
• Field of Search: 707/103.R, 715/762, 715/763, 717/101, 717/116, 719/316, 719/318, 719/312, 719/328
• US Class Current: 719/328
• CPC Class Codes: G06F 1/3203 Power management, i.e. event-based initiation of a power-saving mode
• CPC Class Codes: G06F 11/2082 Data synchronisation
• CPC Class Codes: G06F 16/2365 Ensuring data consistency and integrity
• CPC Class Codes: G06F 21/445 by mutual authentication, e.g. between devices or programs
• CPC Class Codes: G06F 21/6218 to a system of files or objects, e.g. local or distributed file system or database
• CPC Class Codes: G06F 2209/5015 Service provider selection
• CPC Class Codes: G06F 2221/2113 Multi-level security, e.g. mandatory access control
• CPC Class Codes: G06F 2221/2149 Restricted operating environment
• CPC Class Codes: G06F 8/10 Requirements analysis; Specification techniques
• CPC Class Codes: G06F 8/20 Software design
• CPC Class Codes: G06F 8/24 Object-oriented
• CPC Class Codes: G06F 8/30 Creation or generation of source code
• CPC Class Codes: G06F 8/41 Compilation
• CPC Class Codes: G06F 8/61 Installation
• CPC Class Codes: G06F 8/63 Image based installation; Cloning; Build to order
• CPC Class Codes: G06F 8/658 Incremental updates; Differential updates
• CPC Class Codes: G06F 8/71 Version control security arrangements therefor G06F21/57; Configuration management
• CPC Class Codes: G06F 9/449 Object-oriented method invocation or resolution
• CPC Class Codes: G06F 9/4843 by program, e.g. task dispatcher, supervisor, operating system
• CPC Class Codes: G06F 9/5011 the resources being hardware resources other than CPUs, Servers and Terminals
• CPC Class Codes: G06F 9/5027 : the resource being a machine, e.g. CPUs, Servers, Terminals
• CPC Class Codes: G06F 9/5044 : considering hardware capabilities
• CPC Class Codes: G06F 9/5072 : Grid computing
• CPC Class Codes: G06F 9/54 : Interprogram communication
• CPC Class Codes: G06F 9/541 : via adapters, e.g. between incompatible applications
• CPC Class Codes: G06F 9/542 : Event management; Broadcasting; Multicasting; Notifications
• CPC Class Codes: H04L 65/1083 : In-session procedures
• CPC Class Codes: H04L 65/1094 : Inter-user-equipment sessions transfer or sharing
• CPC Class Codes: H04L 65/80 : Responding to QoS
• CPC Class Codes: H04L 67/10 : in which an application is distributed across nodes in the network software deployment G06F8/60; multiprogramming arrangements G06F9/46
• CPC Class Codes: H04L 67/104 : Peer-to-peer [P2P] networks
• CPC Class Codes: H04L 67/1068 : Discovery involving direct consultation or announcement among potential requesting and potential source peers
• CPC Class Codes: H04L 67/1072 : Discovery involving ranked list compilation of candidate peers
• CPC Class Codes: H04L 67/1095 : Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
• CPC Class Codes: H04L 67/14 : Session management for real-time applications in data packet communications networks H04L65/1066
• CPC Class Codes: H04L 67/51 : Discovery or management thereof, e.g. service location protocol [SLP] or web services
• CPC Class Codes: H04L 69/08 : Protocols for interworking; Protocol conversion
• CPC Class Codes: H04L 69/24 : Negotiation of communication capabilities
• CPC Class Codes: H04L 69/328 : in the presentation layer [OSI layer 6]
• CPC Class Codes: H04N 21/41265 : having a remote control device for bidirectional communication between the remote control device and client device unidirectional remote control device H04N21/42204
• CPC Class Codes: Y02D 10/00 : Energy efficient computing, e.g. low power processors, power management or thermal management
• CPC Class Codes: Y02D 30/00 : Reducing energy consumption in communication networks

Abstract

System, device, method, and computer program and computer program products for providing communicating between devices having similar or dissimilar characteristics and facilitating seamless interoperability between them. Computer program software and methods of and systems and devices for sharing of content, applications, resources and control across similar and dissimilar permanently or intermittently connected electronic devices. Devices, systems, appliances, and the like communicating and/or interoperating within the framework provided. A linear tasking method, model, and system provides alternative to conventional pre-emptive and cooperative threading models used on devices so that multiple operations can be specified and run as if their actions were being executed simultaneously. LinearTasking ensures simple, reliable, flexible and extensibe way for processing units to coordinate their activities in very deterministic and easily tested manner.

Claims

1. A method for dynamically ordering and managing a plurality of event processing units and runtime environments that carry out synchronous and asynchronous operations in a required order as part of an event driven runtime of an executing computer program application package, the method comprising:

providing a software object oriented framework which includes a base event processing unit class, and zero or more other event processing unit classes which inherit either directly or indirectly from the base event processing unit class;

creating, maintaining, adding, deleting or reordering runtime links to generate current runtime links that form a graph or topology of the event processing units in a manner that ensures that there is always a single linear deterministic ordering for passing events through the graph of the event processing units formed by the runtime links and for carrying out both synchronous and asynchronous operations in the required order as part of the event driven runtime of the executing computer program application package;

dynamically changing the graph or topology of the event processing units according to the current runtime links and the needs of the executing computer program application package to maintain the single linear deterministic ordering; and

ordering the processing of events includes;

(1) performing any pre-children processing of the event if needed for the particular event being processed;

(2) initially setting or resetting child flags maintained to track the combined event processing needs of all the children event processing units needs along with the needs of all their dependents;

(3) setting up any environment changes needed for each child event processing and call each child event processing unit in the order of the list of children;

(4) collecting the combined event processing type based needs of all the children and their decedents as each call to a child returns;

(5) performing any post-children processing of the event if needed for the particular event being processed;

(6) setting the flags of event type classifications that are now to be handled by this event processing unit in the future; and

(7) returning control to a parent processing unit or to a main processing loop.

2. The method of claim 1, wherein the graph is logically extended to include the graphs of separately generated application packages dynamically during the running of the application package.

3. The method of claim 2, wherein the event processing unit at a topmost node of the separately generated application package'"'"'s graph determines by way of the parameters passed into a event processing method if it is logically a part of an extended graph or actually the start of a topmost application package that is not extended by any other application package.

4. The method of claim 3, wherein if and only if the parameters do not specify an event to process, the topmost node will explicitly attempt to retrieve an event from a queue of events for processing by itself and any other event processing units in the linear order of the graph.

5. The method of claim 2, wherein the event processing unit at a topmost node of the separately generated application package'"'"'s graph determines by way of the parameters passed into a event processing method if it is logically a part of an extended graph or actually the start of a topmost application package that is not extended by any other application package.

6. The method of claim 5, wherein if and only if the parameters do not specify an event to process, the topmost node will explicitly attempt to retrieve an event from a queue of events for processing by itself and any other event processing units in the linear order of the graph.

7. The method of claim 2, wherein there a container event processing unit class is used to instantiate objects to load, link, unload, and manage the environment of separately generated application packages so that their event processing units become a logical extension of the graph.

8. A method as in claim 1, wherein the base event processing unit class further comprises at least one of the following class object members:

possibly null reference to a parent processing unit;

a possibly empty ordered linear list of references to child processing units; and

a procedure for adding, deleting, modifying, and/or reordering a reference to at least one of the parent and child processing units.

9. A method as in claim 8, wherein the base event processing unit class comprises at least one processing unit class object member for ordering the processing of events.

10. A method as in claim 8, wherein the event processing unit base class further comprises the following class object members:

one or more optional binary flag(s) corresponding to classifications of event types that are to be acted upon by the processing unit itself, wherein the flags are used to eliminate unnecessary passing of events down to children or their descendants that will not process any events of a particular class; and

one or more child optional binary flag(s) corresponding to the classes of event types that are to be acted upon by any of the child processing units descending down a chain of parent processing and child processing until there are no more children or child processing units.

11. A method as in claim 1, wherein one or more or any combination of the following are true:

(i) the runtime is the DartRuntime;

(ii) the software object oriented framework is the DartFramework;

(iii) the base event processing units are Dart Gizmos; and

(iv) the event processing unit classes which inherit either directly or indirectly From the base event processing unit class includes either the Dart Rendition class and/or the Dart MasterRendition class.

12. The method of claim 1, wherein the creating, maintaining, adding, deleting, or reordering runtime links includes the reordering of the runtime links whenever there is a created, added, or deleted runtime link that requires the runtime links be reordered to ensure the single linear deterministic ordering for passing events through the graph of the event processing units.

13. The method of claim 1, wherein the creating, maintaining, adding, deleting, or reordering runtime links includes:

creating, maintaining, adding, deleting, and reordering the runtime links.

14. A method for ordering and managing event driven execution and runtime environments of a plurality of event processing units of a computer program software application package, the method comprising:

providing a software object oriented framework which includes a base event processing unit class, and zero or more event processing unit classes which inherit either directly or indirectly from the base event processing unit class;

creating, maintaining, adding, deleting or reordering links that form a graph or topology of event processing units in a manner that ensures that there is always a single linear deterministic ordering for passing events through the graph of processing units formed by the links; and

dynamically changing the graph or topology of processing units according to the needs of the running application;

the base event processing unit class comprises at least one of the following class object members;

(1) a possibly null reference to a parent processing unit;

(2) a possibly empty ordered linear list of references to child processing units;

(3) one or more optional binary flag(s) corresponding to classifications of event types that are to be acted upon by the processing unit itself, wherein the flags are used to eliminate unnecessary passing of events down to children or their descendants that will not process any events of a particular class;

(4) one or more child optional binary flag(s) corresponding to the classes of event types that are to be acted upon by any of the child processing units descending down a chain of parent processing and child processing until there are no more children or child processing units;

(5) a procedure for adding, deleting, modifying, and/or reordering a reference to at least one of the parent and child processing units; and

(6) a procedure for ordering the processing of events;

the base event processing unit class comprising at least one processing unit class object member for ordering the processing of events; and

the procedure for ordering the processing of events is performed according to the following steps;

(1) perform any pre-children processing of the event if needed for the particular event being processed;

(2) initially set (or reset) optional child binary flags maintained to track the combined event processing needs of all the children event processing units needs along with the needs of all their dependents (children), where each optional child flag is a single bit corresponding to exactly one classification of event types, to initially indicate that no events of any of the classifications are to be acted upon by children or their decedents;

(3) set up any environment changes needed for each child processing and call each child event processing unit in the order of the list of children;

(4) as each call to a child returns, logically OR the optional child binary flags of processing types needed to be processed by each of the just called child to collect the combined event processing type based needs of all the children and their decedents;

(5) perform any post-children processing of the event if needed for the particular event being processed;

(6) set the binary flags of event type classifications that are now to be handled by this event processing unit in the future;

(7) return control to a parent processing unit if the parent reference is a first state; and

(8) return control to a main processing loop which logically called this processing unit if the parent reference is a second state.

15. A method as in claim 14, wherein the optional pre-children and or post-children processing of the event is based on at least one of:

(i) the event type;

(ii) the events fields, parameters and/or associated file contents values, and/or those on any list of referenced child processing units to the tasks of the processing unit; and

(iii) the current run-time environment as specified by the event, the parent, and or the state of the device.

16. A method as in claim 14, wherein the set up of any environmental changes needed may optionally include at least one of providing a bitmap as a virtual screen, distorting the child'"'"'s sense of time, distorting the coordinates of a mouse click to conform to the different size, translation or angle of orientation the parent is displaying of the image or bitmap the child processing unit is rendering into.

17. A method as in claim 14, wherein managing the links is used to flexibly and dynamically mix and match event processing units in a manner where changes in functionality are easily made by creating and maintaining the ordered graph.

18. A method as in claim 14, wherein where the environment for linked processing units can be controlled by a parent processing unit to provide advanced functionality without the need for the child processing units to understand how their environments are being virtualized by parent processing units.

19. A method as in claim 14, wherein the deterministic flow of processing makes for a robust system because the order of event processing is more tightly controlled and more easily tested than they would be in non-deterministic asynchronous event processing runtimes.

20. A method as in claim 14, wherein processing units compiled into one Dart can proxy for separately compiled and generated Darts that can dynamically be added to the Linear Tasking graph and then function as if they were part of the originally generated Dart.

21. A method as in claim 20, wherein separately generated Darts can be saved automatically as parts of parent Darts as the result of a SAVE_INSTRUCTION or SAVE_BUILTIN_INSTRUCTION.

22. A computer program product for use in conjunction with a computer system or information appliance, the computer program product comprising a tangible computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism comprising:

a program module that directs the computer system or information appliance to function in a specified manner for dynamically ordering and managing a plurality of event processing units and runtime environments that carry out synchronous and asynchronous operations in a required order as part of an event driven runtime of an executing computer program application package, the program module including instructions for;

generating or providing a software object oriented framework which includes a base event processing unit class, and zero or more other event processing unit classes which inherit either directly or indirectly from the base event processing unit class;

creating, maintaining, adding, deleting or reordering runtime links to generate current runtime links that form a graph or topology of the event processing units in a manner that ensures that there is always a single linear deterministic ordering for passing events through the graph of the event processing units formed by the runtime links and for carrying out both synchronous and asynchronous operations in the required order as part of the event driven runtime of the executing computer program application package;

dynamically changing the graph or topology of the event processing units according to the current runtime links and the needs of the executing computer program application package to maintain the single linear deterministic ordering; and

ordering the processing of events includes;

(1) performing any pre-children processing of the event if needed for the particular event being processed;

(2) initially setting or resetting child flags maintained to track the combined event processing needs of all the children event processing units needs along with the needs of all their dependents;

(3) setting up any environment changes needed for each child event processing and call each child event processing unit in the order of the list of children;

(4) collecting the combined event processing type based needs of all the children and their decedents as each call to a child returns;

(5) performing any post-children processing of the event if needed for the particular event being processed;

(6) setting the flags of event type classifications that are now to be handled by this event processing unit in the future; and

(7) returning control to a parent processing unit or to a main processing loop.

23. A computer program product as in claim 22, wherein the base event processing unit base class further comprises at least one of the following class object members:

a possibly null reference to a parent processing unit;

a possibly empty ordered linear list of references to child processing units; and

a procedure for adding, deleting, modifying, and/or reordering a reference to at least one of the parent and child processing units.

24. The computer program product of claim 23, wherein the event processing unit base class further comprises the following class object members:

one or more optional binary hag(s) corresponding to classifications of event types that are to be acted upon by the processing unit itself, wherein the flags are used to eliminate unnecessary passing of events down to children or their descendants that will not process any events of a particular class; and

one or more child optional binary flag(s) corresponding to the classes of event types that are to be acted upon by any of the child processing units descending down a chain of parent processing and child processing until there are no more children or child processing units.

25. The computer program product of claim 22, wherein the creating, maintaining, adding, deleting, or reordering runtime links includes the reordering of the runtime links whenever there is a created, added, or deleted runtime link that requires the runtime links be reordered to ensure the single linear deterministic ordering the passing events through the graph of the event processing units.

26. The computer program product of claim 22, wherein the creating, maintaining, adding, deleting, or reordering runtime links includes:

creating, maintaining, adding, deleting, and reordering the runtime links.

27. An apparatus providing ordering and managing of event driven execution and runtime environments of a plurality of event processing units, the apparatus comprising:

a processing logic or processor and a memory coupled with the processing logic or processor;

means, accessible to the processing logic or processor, for generating or providing a software object oriented framework which includes a base event processing unit class, and zero or more other event processing unit classes which inherit either directly or indirectly from the base event processing unit class;

means, accessible to the processing logic or processor, for creating, maintaining, adding, deleting or reordering runtime links to generate current runtime links that form a graph or topology of the event processing units in a manner that ensures that there is always a single linear deterministic ordering for passing events through the graph of the event processing units formed by the runtime links and for carrying out both synchronous and asynchronous operations in the required order as part of the event driven runtime of the executing computer program application package;

means, accessible to the processing logic or processor, dynamically changing the graph or topology of the event processing units according to the current runtime links and the needs of the executing computer program application package to maintain the single linear deterministic ordering and

means for ordering the processing of events, including;

(1) means for performing any pre-children processing of the event if needed for the particular event being processed;

(2) means for initially setting or resetting child flags maintained to track the combined event processing needs of all the children event processing units needs along with the needs of all their dependents;

(3) means for setting up any environment changes needed for each child event processing and call each child event processing unit in the order of the list of children;

(4) means for collecting the combined event processing type based needs of all the children and their decedents as each call to a child returns;

(5) means for performing any post-children processing of the event if needed for the particular event being processed;

(6) means for setting the flags of event type classifications that are now to be handled by this event processing unit in the future; and

(7) means for returning control to a parent processing unit or to a main processing loop.

28. A method comprising:

dynamically managing a plurality of event processing units and runtime environments that carry out asynchronous processing operations in a required order as part of an event driven runtime of an executing computer program;

the dynamic managing further including;

providing a software object oriented framework which includes a base event processing unit class, and zero or more other event processing unit classes which inherit either directly or indirectly from the base event processing unit class;

adding runtime links or deleting runtime links and reordering the runtime links to generate a current runtime links set for the event processing units to ensure that there is always a single linear deterministic ordering for processing events through the event processing units for carrying out both synchronous and asynchronous operations in the required order as part of the event driven runtime of the executing computer program; and

dynamically changing the event processing units according to the current runtime links and the needs of the executing computer program to maintain the required order of the single linear deterministic ordering; and

ordering the processing of events that includes the steps of;

(1) performing any pre-children processing of the event if needed for the particular event being processed;

(2) initially setting or resetting child flags maintained to track the combined event processing needs of all the children event processing units needs along with the needs of all their dependents;

(3) setting up any environment changes needed for each child event processing and call each child event processing unit in the order of the list of children;

(4) as each call to a child returns, collecting the combined event processing type based needs of all the children and their decedents;

(5) perform any post-children processing of the event if needed for the particular event being processed;

(6) setting the flags of event type classifications that are now to be handled by this event processing unit in the future;

(7) returning control to a parent processing unit if the parent reference is a first state; and

(8) returning control to a main processing loop which logically called this processing unit if the parent reference is a second state.