Untergeordnete Seiten
  • Service Registration

  Wiki Navigation

    Loading...


 Recently Updated


 Latest Releases

 MediaPortal 1.32
            Releasenews | Download
 MediaPortal 2.5
            Releasenews | Download


Motivation

MediaPortal 2 is a huge application, consisting of many different modules. Some easy modules are self-contained (like the logging module), but many of them depend on other of those modules, for example the PlayerManager needs to make calls on the PluginManager. Such modules need a way to access those services without holding a direct reference to them. This enables a less coupled system.

ServiceRegistration - getting instances of application services

The ServiceRegistration class is responsible for holding all application-wide accessible service instances. A service in this context is an object which fulfills a specific function, defined by a service interface. A service can be responsible for logging (interface ILogger), messaging (IMessageBroker) or other application tasks. The ServiceRegistration class supplies methods to get, set and remove a service for a special interface.

So the ServiceRegistration is the globally accessible singleton registration throughout the MP2 application.

For more information, see the docs for class MediaPortal.Core.ServiceRegistration.

Rules for using ServiceRegistration

  • Because the ServiceRegistration should decouple the system, it is undesired that some application module stores an internal reference to a system service for longer than inside a call frame (a method). There might be exceptions to this rule, but in general it should be kept. => Only local references to services which were obtained through the ServiceRegistration are allowed
  • To avoid multithreading issues, don't hold a lock while you call a globally accessible module, if the current lock is also able to be obtained globally directly or indirectly (see Multithreading in MP2). The reason is that if you hold a globally obtainable lock while calling a service, and the service does the same with its own lock while calling code trying to obtain your lock, we'll get a deadlock. Because it is VERY COMPLICATED to become aware of such lock cascades and to find such deadlocks, it is simply not allowed to do so. => Don't call other globally accessible code (which might also use locking) while holding a lock which is also globally accessible.

   

 

This page has no comments.