WO2011001209A1

WO2011001209A1 - Resource allocation in a computing device

Info

Publication number: WO2011001209A1
Application number: PCT/IB2009/052813
Authority: WO
Inventors: Francesco Lodolo
Original assignee: Nokia Corporation
Priority date: 2009-06-29
Filing date: 2009-06-29
Publication date: 2011-01-06

Abstract

A method of allocating resources in a computing device where resources are allocated to clients according to requests from the clients, said allocation of resources being at least partially determined by system settings, said computing device comprising a message queue where a request from a client for a resource allocation has a corresponding message in said queue and wherein a change which may affect an existing resource allocation is processed as a message in said queue. Said change which may affect a resource allocation may arise from a change to a user profile, a change to a system setting or from a change to a hardware component of said computing device.

Description

RESOURCE ALLOCATION IN A COMPUTING DEVICE

TECHNICAL FIELD

The present invention relates to the allocation of resources in a computing device.

BACKGROUND TO THE INVENTION

Computing devices are increasingly becoming more versatile and capable of completing more tasks than was previously possible. Together with this increase in capabilities there exists a commensurate increase in resources used by the computing device to perform these tasks.

The increase in the number of resources increases the complexity in managing the resources. In the past, the management of resources was treated in an ad hoc manner. Any conflicts in requests for, or the use of, resources would either be specified for the particular requests and resources concerned, or would result in an error.

Recently however the realisation has arisen that a framework needs to be provided in the computing device to manage the allocation of resources which is able to deal with conflicts to the resources and the requests for allocation. Generally, such systems are concerned with receiving requests for resource allocation from clients (which may be software or hardware components) and allocating the resources according to a set of rules.

A particular problem with such systems is that changes to the rules according to which the resources are allocated are not applied to resource allocations which were allocated prior to the change. A similar problem pertains to other changes which may affect existing resource allocations: no consistent or standardised manner exists for dealing with such changes which ensures that all existing resource allocations are reevaluated to take the changes into account. This can lead to a frustrating user experience at best, and errors in resource allocations at worst.

In a number of systems for resource allocation, such as the multimedia subsystem of the Symbian operating system, requests for resource allocation are dealt with in a queue.

SUMMARY OF THE INVENTION

According to an embodiment of the invention, a method of allocating one or more of a plurality of resources in a computing device to a client according to a request originating from the client is provided, the method including the steps of:

placing a message corresponding to said request in a queue of messages;

processing said message corresponding to said request by allocating a resource to the client with reference to a system setting; and

maintaining a record of the resource allocated to the client, said method further comprising the step of:

processing a change which may affect said resource allocation as a message in said queue.

By processing a change which may affect the resource allocation as a message in the queue, embodiments of the invention are able to ensure that resource allocations are changed when the availability of the corresponding resources are affected or when other, more appropriate resources for the allocation become available. Furthermore, embodiments are able to ensure that changes to the resources which are currently allocated are permeated quickly throughout the system and affect not only subsequent resource allocations but existing resource allocations too. Furthermore, by processing the change which may affect the resource allocation as a message in the queue, embodiments of the invention ensure that any changes which do affect resource allocation may be applied to existing resource allocations in a manner which does not interfere with any other processing which may be taking place. This avoids conflicts where a resource is allocated in contravention of a change to the resource because the two are being processed simultaneously.

The change which may affect said resource allocation may comprise a change affecting at least one of said resource or said client request.

Said change which may affect an availability of said resource may affect the availability of the resource by blocking access to the resource or by changing a routing so that the resource is no longer available. Alternatively, said change to said setting may stipulate that a different resource be utilised for the resource allocation.

Furthermore, the change may affect the availability of the resource by affecting the client request in such a manner that the resource allocated by the resource allocation is no longer appropriate.

The change which may affect said resource allocation may result from a change in a system setting or a hardware component.

The system setting which gives rise to the change which may affect the resource allocation may be the same system with reference to which the resource was allocated. Alternatively, the device comprises a plurality of system settings and the system settings are interconnected to that said resource is allocated with reference to a first system setting and a change to a second system resource causes said change which may affect said resource allocation. In certain situations (e.g. where a new hardware component is installed) a change to both a hardware component and at least one system setting will occur and both of these may precipitate said step of processing said change.

Embodiments of the invention are able to process changes to both system components and hardware components quickly where these changes affect the allocation of resources in the computing device. Furthermore, embodiments of the invention are able to process changes to both system settings and hardware components, as well as changes to a plurality of system settings and hardware components in an orderly manner without the risk of conflicts arising as each change is processed as a message in said queue.

The change which may affect said resource allocation may result from a user profile change.

Embodiments according to the invention significantly improve the user experience by allowing the user to easily control and change the allocation of resources through a single action.

The user profile change may result in a change to a system setting.

The change to said user profile may cause a system state manager of said computing device to generate said message corresponding to said change which may affect said resource allocation.

A system state manager is a centralised component which provides information regarding the states of the device. This includes the states of the hardware components and any software components which may have a bearing on the general state of the computing device. The system state manager may generate messages for said queue when a hardware component changes its state. Similarly, where a user profile change results in a change which may affect the resource allocation, the system state manager generates said message corresponding to said change. This provides a centralised source for said messages which is relatively easy to manage and to adapt to changing device characteristics.

The change which may affect said resource allocation may be caused by a change to a hardware component where said change to said hardware component comprises one or more of: said hardware component being installed in said computing device, said hardware component being removed from said computing device, or a state of said hardware component changing.

Where the resource which is allocated to the client request comprises a hardware component which is removed or the state of which is changed, embodiments of the invention are able to allocate alternate resources to that client where the client request is incompatible with said removal or said state change. Similarly, where a new hardware component is added the resource allocated to the client may be changed where it is determined that the new hardware component is more appropriate to the client request.

The system setting may relate to one or more of: a routing policy, a memory- related policy, a battery usage policy, a topology policy, a pre-emption policy.

The step of processing said change which may affect said resource allocation may comprise re-analysing said maintained record of said resource allocated to said client.

By analysing the maintained records of the resource allocated to the client, embodiments of the invention are able to determine whether the change does affect the allocation of the resource and is able to determine what steps are necessary to correctly service the client request taking this change into account. The maintained record of the resource acts as a representation of the allocation which may be referenced when the calculation is made whether or not this allocation should be changed. This avoids the need to recalculate the allocation prior to analysing the effects of the change.

The method may include the additional step of altering said resource allocation if said change has affected said resource allocation.

The resource allocation may be altered with reference to one or more system settings.

The queue may be capable of storing a plurality of messages, said messages being processed sequentially.

As the queue is able to store a plurality of messages which are processed sequentially, requests from clients as well as changes which may affect resource allocation can be processed in the same queue without interfering with one another.

The computing device may comprise a plurality of resources and a plurality of clients wherein a corresponding record is maintained for each resource allocated to a client.

Embodiments extend to analysing each maintained record and determining whether the corresponding resources have been affected by the change.

The system setting may govern a plurality of resources of said computing device and said step of processing said change which may affect said resource allocation may comprise the further steps of analysing a maintained record corresponding to each affected resource.

The resources may be multimedia resources and may include at least one media source, media effect, decoder, encoder or media sink. The record of the resource allocated to the client may comprise at least one filter graph, said filter graph linking said client and said resource of said record.

Filter graphs are particularly effective at representing an allocation of a resource to a client. In particular, with reference to multimedia resources and corresponding clients, graphs generally include a source derived from one of the clients and a sink corresponding to a resource.

Further embodiments extend to a program for a program for a computing device adapted to perform the aforementioned methods, an operating system incorporating such a program as well as a computing device incorporating such an operating system. BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are hereinafter described with reference to the accompanying diagrams where like numerals are used to refer to like components and where:

Figure 1 is a schematic representation of a mobile computing device;

Figure 2 is a schematic representation of elements of the mobile computing device of Figure 1 ;

Figure 3 is a schematic representation of connections between client applications and a context manager;

Figure 4 is a schematic representation of connections between system components and a system state manager;

Figure 5 is a schematic representation of a system settings interface of the mobile computing device of Figure 1 ;

Figure 6 is a schematic representation of the connections of elements of a multimedia subsystem of the mobile computing device of Figure 1;

Figure 7 is a schematic representation of a message queue;

Figure 8 is a process diagram illustrating the operation of a method; Figure 9 is a process diagram illustrating a further operation of a method; and Figure 10 illustrates two filter graphs.

DETAILED DESCRIPTION

Figure 1 is a schematic diagram of an exemplary mobile computing device 10 having a casing 12. The casing 12 encapsulates a keypad 14, a screen 16, a speaker 18 and a microphone 20. The device 10 further includes an antenna 22. The mobile computing device 10 illustrated in Figure 1 may function as a phone and, in this instance, sends and receives telecommunication signals via antenna 22.

Figure 2 is a schematic illustration of certain components of the mobile computing device 10. Device 10 includes a kernel 38 which represents the operating system of the device 10. In the embodiment shown, the operating system is the Symbian operating system. The kernel 38 is connected to a system memory 36 which is controlled by means of a memory management unit 34. Device drivers 24, 26 and 28 are connected to the kernel 38 and control the behaviour of, and communication with, respective devices: keyboard 14, display 16 and network card 30. A user interacts with the device 10 by means of user programs, one of which, user program 32, is illustrated in Figure 2. User program 32 communicates with the hardware of the device 10 (such as the display 16) by means of the kernel 38. It is to be realised that the mobile computing device 10 includes many more devices and components than those illustrated here.

The system memory 36 contains the software needed to operate the device 10 and, when the device is switched on, software in the system memory establishes the kernel 38, device drivers 24, 26 and 28, user program 32 and all other required software. The software may be copied to the system memory 36 during manufacture of the device 10 as a software image. Embodiments of the invention will be hereinafter described with reference to the Symbian operating system and, in particular, the multimedia subsystem of the

Symbian operating system. It is to be realised however that the invention is not limited in this respect and may just as easily be applied to apparatus that use other operating systems, and to the allocation of resources other than multimedia resources.

Figure 3 illustrates a context manager 50 which forms part of the kernel 38 illustrated in Figure 2. The context manager 50 is connected to a plurality of user programs of which three: media player 52, gaming application 54 and presentation application 56 are illustrated in Figure 3. It is to be realised however that many more such user programs may be connected to context manager 50 and that the illustration of Figure 3 is presented merely by way of example. Each software component (other than those forming part of the kernel 38) which may require a multimedia resource is registered with the context manager and the context manager manages these resources in a manner described below. The context manager 50 is concerned with software applications in user space.

Figure 4 illustrates a system state manager 60 which forms part of the kernel 38 and which is connected to a plurality of system components. In the depiction of Figure 4, the following system components are connected to system state manager 60: volatile memory 62, battery 64, central processing unit (CPU) 66, non-volatile memory 68 and user profile monitor 69. Once again, it is to be realised that the depiction of Figure 4 is presented merely by way of example and that the system state manager 60 may be connected to different resources. The system state manager may be connected to any software component forming part of the kernel 38, and to any hardware component, which affect the system state and which may require a system notification to be issued to the user of the device or to any hardware component which may affect the system settings described below.

So, for example, the system state manager 60 is connected to battery 64 and when the battery reaches a predetermined charge level (generally a charge level which requires action by the user to prevent the device from becoming inactive) the system state manager is made aware thereof and will initiate the process whereby a notification is issued to the user.

Similarly, the system state manager 60 monitors the volatile memory 62, CPU 66 and non-volatile memory 68 and determines when notifications in respect of these components are to be issued.

The user profile monitor 69 may be connected to user profiles. Each user profile specifies, amongst others, settings which affect the multimedia subsystem. For example, a certain user profile may direct all audio output to a vibrator (not shown), specify a maximum volume, specify a default video display device etc. Therefore, the user profile monitor 69 monitors the current active profile and if a setting of this profile is changed, then the user profile monitor 69 informs the system state manager 60 thereof. Where the change relates to resources for the multimedia subsystem the system state manager 60 initiates the process whereby a re-allocation of multimedia resources can occur (in the manner described below).

Figure 5 illustrates system settings interface 70 which may comprise part of the kernel 38 of the computing device illustrated in Figures 1 and 2. The system settings interface 70 is an interface to those settings of the computing device which affect and influence a manner in which multimedia resources might be allocated to particular clients. The interface 70 of Figure 5 provides an interface to the following system settings: routing 72, memory 74, battery 76, topology 78 and pre-emption 80. Each of these system settings may, under certain circumstances, affect the manner in which resources may be allocated.

The pre-emption system settings 80 determine which processes have precedence over other processes. The topology system settings 78 determine the connections of multimedia resources such as screens and speakers or headphones and the routing system settings 72 which determine how a particular resource may be accessed. Memory system settings 74 and battery system settings 76 determine how resources are allocated in dependence on the state of the memory and the battery, respectively.

Therefore the system settings which are interfaced by the interface 70 furthermore provide a set of policies which determines how resources are to be allocated in dependence on the states and characteristics of components of the computing device 10.

It is to be realised that the system settings illustrated in Figure 5 are shown merely by way of example and that an interface may be provided to many other system settings. For example, other system settings determine how resources are to be allocated in dependence on the state of other hardware components such as the CPU state.

The system state manager 60 of Figure 4 has access to the system settings illustrated in Figure 5 and is able to determine those system settings which pertain to the components monitored by the system state manager. For example, whilst the system state manager 60 may be connected to the battery 64, the battery system setting 74 determines the parameters which determine when the system state manager 60 issues a notification relating to the status of the battery.

For other operations of the system state manager 60, reference may be made to corresponding settings interfaced at 70, or the system state manager 60 may have access to rules independent of the interface 70 which determine the appropriate action to be taken by the system state monitor 70.

Figure 6 illustrates the connections of elements of a multimedia subsystem of the computing device 10. The multimedia subsystem comprises context manager 50 described above with reference to Figure 3. The context manager 50 is connected to a message queue 100 which is, in turn, connected to the system state manager 60 described above with reference to Figure 4.

The context manager 50, message queue 100 and system state manager 60 are all connected to a controller 82. The controller 82 is further connected to the interface 70 described above with reference to Figure 5 and the interface 70 is connected to a blackboard 90.

The blackboard 90 is connected to the context manager 50 and to the system state manager 60. The context manager 50 (as described above) is connected to user applications which form a portion of the clients of the media subsystem illustrated in Figure 6. The context manager 50 receives and handles requests for resources from these clients. Similarly, the system state manager 60 receives and handles system requests.

The context manager 50 and the system state manager 60 both receive requests for resource allocation from respective clients. Once the client request is received, a corresponding message is generated and placed in queue 100.

The controller 82 monitors the message queue 100 and when the message queue presents a new request to the controller 82 this is communicated to the system settings interface 70 and the request is written to the blackboard 90. The interface 70 accesses the corresponding request from the blackboard 90. If the system settings are able to service the particular request (in other words provide rules whereby a resource may be allocated to that request), this will result in a graph (as described in greater detail below) and the graph is written to the blackboard 90. Therefore, the blackboard 90 maintains records (in the form of graphs) corresponding to client requests and the resources allocated to these client requests.

Figure 7 illustrates the message queue 100 which comprises a plurality of messages 102. Only a portion of the message queue 100 is illustrated in Figure 7 for the size and number of messages in the queue will vary during the operation of the multimedia subsystem illustrated in Figure 6 and will additionally vary depending on the details of the mobile computing device in which the multimedia system is implemented. The message queue 100 may be a first in, first out queue so that the controller 82 will access the messages of the message queue 100 in the order in which they were written to this queue; however, other queuing techniques may also be used.

The operation of the multimedia subsystem illustrated in Figure 6 will now be described with reference to the process of Figure 8. The process begins at step 202 where a client request is generated. As described, this occurs at the context manager 50 or at the system state manager 60. Once the client requests have been generated, the process moves to step 204 where the client request is added to the message queue 100. Then at step 206, the controller 82 will access the message queue 100 to retrieve the next message in the queue. As described, the messages in the illustrated queue 100 are processed in a first in, first out basis.

Step 208 represents the first step in which the controller processes the message retrieved from the message queue at step 206. At step 208, the controller will publish the request to the blackboard 90. It is to be realised that the request which is published to the blackboard 90 corresponds to the particular message retrieved from the message queue 100. At the following step, step 210, the system settings interface 70 accesses the blackboard 90 and retrieves the request corresponding to the message retrieved from the message queue 100. At step 212 the controller 82 iterates through each of the system settings for which an interface is provided to determine whether the request can be met or not. The iteration of the system settings involves the accessing of each of the system settings connected to interface 70 and determining whether the request can be met by that system setting.

At the following step, step 214, a decision is made whether the request may be serviced or not. This involves aggregating the decisions received by iterating through all the system settings in step 212 and making a decision based thereon. If it is determined at step 214 that the request cannot be serviced the process proceeds to step 224 where an error is generated. Alternatively, if it is determined at step 214 that the request may be serviced, the process proceeds to step 216 where the controller 82 is informed that the request may be serviced. At the following step, step 218, the controller then writes the graph which corresponds to the client request and the resource then allocated to that client request to the blackboard 90. At the following step, step 220, the controller will inform the client and pass the client the control over the resource now allocated to this. The process will then proceed to step 222 where the controller 82 retrieves the next message from the message queue 100. Alternatively, at step 222, if there are no more messages to be processed in the message queue 100, the controller 82 will await the next message to be written to the message queue 100.

Figure 9 illustrates a process 240 whereby a user profile update is processed by the multimedia subsystem illustrated in Figure 6. As previously discussed, user profiles may influence system settings and therefore influence the determination of whether a particular resource may be allocated to a particular client request. From the aforementioned description, it will be realised that a change to the active user profile will only be reflected in graphs created after the profile change occurred unless steps are taken to ensure that all existing graphs reflect the change in the profile.

In the initial step, step 242, the active user profile is updated. At the following step, step 244, the user profile monitor 69 detects that the active user profile has been updated and informs the system state manager 60. At following step 254, the system state manager 60 generates a message which is added to the queue 100. At the following step, step 256, the controller 82 accesses the message queue 100 in the manner described above and retrieves the message corresponding to the change in the profile. The controller 82 reacts to the message corresponding to the change in the profile by accessing the blackboard 90 and retrieving each of the graphs affected by the profile change stored in the blackboard 90. Therefore, at step 258 (in the first iteration) the first graph stored in blackboard 90 is retrieved. Then, at step 260, the graph retrieved in step 258 is evaluated and a decision is made (at the following step 262), whether the graph is affected by the profile change.

If it is determined at step 262 that the particular graph has been affected by this policy change, the process will proceed to step 268 where the graph is re-evaluated in terms of the updated system settings affected by the changed profile. Then at the following step, step 270, the re-evaluated graph will be written to the blackboard 90 and the corresponding client will be informed of the new graph. The process will then proceed to step 264 where a determination is made whether the last graph stored in the blackboard 90 has been processed. If it is determined at step 264 that there are additional graphs to process the process will return to step 258 and the next graph will be processed accordingly. Alternatively, if it is determined that step 264 that there are no additional graphs to process, the process will proceed to 266 where it will terminate. Figure 9 illustrates the process whereby the changes to a user profile result in changes to system settings and the affected graphs are re-evaluated. By way of example, a user alters the default audio sink (to an external speaker). Each of the currently active graphs is then evaluated and each graph which utilises the default audio signal is re-evaluated to replace the audio sink that that one which is now specified by the user.

It is to be realised however that embodiments of the invention are equally applicable to any other change which may affect the current resource allocations. For example, if a new hardware component is added and this hardware component affects the multimedia subsystem then all of those graphs which are affected may be reevaluated according to the process of Figure 9 (with the only change being that the system state manager 60 will generate the message corresponding to this change not in response to a prompt by the user profile monitor 69, but rather in response to another component responsible for the monitoring of installed hardware).

Figure 10 illustrates two graphs created according to some embodiments.

Graph 300 represents the allocation of resources to a media player 302 which is in the process of playing an MP3 file. The media player client communicates the request to the context manager 50 specifying that the source is an MP3 file and requesting an MP3 decoder as well as the default audio output. In this example, the MP3 decoder and the default audio output requested by the media player represent the resources to be allocated. The system settings interfaced by system settings interface 70 would allocate the correct MP3 decoder 306 and the default audio output 312 to the resource request generated by the media player 302 according to any rules pertaining thereto. As a result of this, the graph 300 illustrated in Figure 10 would arise. The media player 302 includes a source 304 which is connected to a sink 308 of MP3 decoder 306. MP3 decoder 306 also includes a source 310 which is connected to a sink 314 of the default audio output 312.

Similarly, Figure 10 illustrates a graph 330 which corresponds to the system state manager 60 requesting an audio notification to a user of the device 10. The system state manager is represented in the graph 330 by block 332 which includes a source 334. In this example the source 334 is the particular notification to be issued which may, for example, be an MP3 sound file. The source 334 is connected to a sink on a notification server 336. The notification server is able to receive the sources for notifications and quickly reproduce the required notification. The notification server 336 includes a source 340 which is connected to a sink 344 or the default audio output

312.

Both graph 300 and graph 330 utilise the default audio output. When these graphs are written to the blackboard 90 they will be written where the block 312 represents the default audio output at the time the graph is constructed (as described above). However, where the default audio output changes, embodiments of the invention ensure that both graph 300 and graph 330 are read from the blackboard 90 and changed to reflect the new default audio output.

As used here in, the term "resource" relates to any software or hardware component which may be utilised to service a particular request. With reference to a multimedia system, the term "requests" may refer to software components such as media sources, media effects, media decoders and media encoders and/or hardware components such as speakers, displays, microphones, bluetooth headsets etc.

Embodiments of the present invention may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. The software, application logic and/or hardware may reside in a processor, in memory or in dedicated hardware circuitry. In an example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a "computer- readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device. A computer-readable medium may comprise a computer-readable storage medium that may be any media or means that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device.

If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the above-described functions may be optional or may be combined.

Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

It is also noted herein that while the above describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.

Claims

1. A method comprising:

placing a message corresponding to said request in a queue of messages;

processing said message corresponding to a request originating from a client by allocating a resource of a computing device to the client with reference to a system setting;

maintaining a record of the resource allocated to the client; and

2. The method according to claim 1 wherein said change which may affect said resource allocation comprises a change affecting at least one of said resource or said client request.

3. The method according to claim 1 or claim 2 wherein said change which may affect said resource allocation results from a change in a system setting or a hardware component.

4. The method according to claim 3 wherein said change which may affect said resource allocation results from a user profile change.

5. The method according to claim 4 wherein said user profile change results in a change to a system setting.

6. The method according to claim 4 or claim 5 wherein said change to said user profile causes a system state manager of said computing device to generate said message corresponding to said change which may affect said resource allocation.

7. The method according to any of claims 3 to 6 wherein said change which may affect said resource allocation is caused by a change to a hardware component and said change to said hardware component comprises one or more of: said hardware component being installed in said computing device, said hardware component being removed from said computing device, or a state of said hardware component changing.

8. The method according to any preceding claim wherein said system setting relates to one or more of: a routing policy, a memory-related policy, a battery usage policy, a topology policy, a pre-emption policy.

9. The method according to any preceding claim wherein said step of processing said change which may affect said resource allocation comprises re- analysing said maintained record of said resource allocated to said client.

10. The method according to claim 9 which includes the additional step of altering said resource allocation if said change has affected said resource allocation.

11. The method according to claim 10 wherein said resource allocation is altered with reference to one or more system settings.

12. The method according to any preceding claim wherein said queue is capable of storing a plurality of messages, said messages being processed sequentially.

13. The method according to claim 12 wherein said computing device comprises a plurality of resources and a plurality of clients wherein a corresponding record is maintained for each resource allocated to a client.

14. The method according to claim 13 wherein said system setting governs a plurality of resources of said computing device and wherein said step of processing said change which may affect said resource allocation comprises the further steps of analysing a maintained record corresponding to each affected resource.

15. The method according to any preceding claim wherein said resources are multimedia resources and include at least one media source, media effect, decoder, encoder or media sink.

16. The method according to claim 15 wherein said record of the resource allocated to the client comprises at least one filter graph, said filter graph linking said client and said resource of said record.

17. Apparatus comprising:

at least one processor; and

at least one memory including computer program code; the at least one memory and the computer program code being configured to, working with the at least one processor, cause the apparatus to perform at least the following:

cause a message corresponding to said request to be placed in a queue of messages;

cause said message corresponding to a request originating from a client to be processed by allocating a resource of a computing device to the client with reference to a system setting;

cause a record to be maintained of the resource allocated to the client; and cause a change which may affect said resource allocation to be processed as a message in said queue.

18. Apparatus according to claim 17 wherein said change which may affect said resource allocation comprises a change affecting at least one of said resource or said client request.

19. Apparatus according to claim 17 or claim 18 wherein said change which may affect said resource allocation results from a change in a system setting or a hardware component.

20. Apparatus according to claim 19 wherein said change which may affect said resource allocation results from a user profile change.

21. Apparatus according to claim 20 wherein said user profile change results in a change to a system setting.

22. Apparatus according to claim 20 of claim 21 wherein said change to said user profile causes a system state manager of said computing device to generate said message corresponding to said change which may affect said resource allocation.

23. Apparatus according to any of claims 19 to 22 wherein said change which may affect said resource allocation is caused by a change to a hardware component and said change to said hardware component comprises one or more of: said hardware component being installed in said computing device, said hardware component being removed from said computing device, or a state of said hardware component changing.

24. Apparatus according to any of claims 17 to 22 wherein said system setting relates to one or more of: a routing policy, a memory-related policy, a battery usage policy, a topology policy, a pre-emption policy.

25. Apparatus according to any of claims 17 to 22 wherein causing said change which may affect said resource allocation to be processed comprises causing said maintained record of said resource allocated to said client to be re-analysed.

26. Apparatus according to claim 25, wherein the at least one memory and the computer program code are further configured to, working with the at least one processor, cause the apparatus to:

cause said resource allocation to be altered if said change has affected said resource allocation.

27. Apparatus according to claim 26 wherein causing said resource allocation to be altered comprising causing said resource allocation to be altered with reference to one or more system settings.

28. Apparatus according to any of claims 17 to 27 wherein said queue is capable of storing a plurality of messages, said messages being processed sequentially.

29. Apparatus according to claim 28 wherein said computing device comprises a plurality of resources and a plurality of clients wherein a corresponding record is maintained for each resource allocated to a client.

30. Apparatus according to claim 29 wherein said system setting governs a plurality of resources of said computing device and wherein causing said change which may affect said resource allocation to be processed comprises causing a maintained record corresponding to each affected resource to be analysed.

31. Apparatus according to any of claims 17 to 30 wherein said resources are multimedia resources and include at least one media source, media effect, decoder, encoder or media sink.

32. Apparatus according to claim 31 wherein said record of the resource allocated to the client comprises at least one filter graph, said filter graph linking said client and said resource of said record.

33. A program for a computer adapted to perform the method of any one of claims 1 to 16.

34. A computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer, the computer program code comprising:

code for placing a message corresponding to said request in a queue of messages;

code for processing said message corresponding to a request originating from a client by allocating a resource of a computing device to the client with reference to a system setting;

code for maintaining a record of the resource allocated to the client; and code for processing a change which may affect said resource allocation as a message in said queue.