MXPA00003387A - Multithread data processor - Google Patents

Abstract

In a first aspect, the present invention comprises an apparatus for processing digital audio-visual data, in particular, a receiver/decoder for a digital television system, comprising one or more hardware devices for transmission and reception of data, the hardware devices having at least one associated hardware operating system (4100), the decoder further comprising a data processing system including a multi-thread virtual machine (4250) adapted to, inter alia, receive event messages signalled by the hardware operating system and to assign corresponding event objects (4564) to one or more threads (4561), and in which a thread including an event object may be suspended during the course of its execution to permit the execution of another thread. Viewed from a second aspect, the present invention relates to an apparatus for processing digital audio-visual data comprising a data processing system including a first virtual machine adapted to, inter alia, receive code written in an interpretative language downloaded via one or more of the hardware devices, said virtual machine being adapted to distinguish between code written in at least two interpretative languages in dependence on the structure of the received code and to pass such code to a corresponding interpreter means for interpretation and execution in particular with reference to a common or specific function library. Viewed from a third aspect, the present invention comprises an apparatus for processing digital audio-visual data including a data processing system including a memory and a memory manager for allocating and storing objects in the memory, and in which a first set of objects are allocated by the memory manager with referenceto a set of handles, each handle including a reference to the memory address of a corresponding object, and in which a second set of objects are allocated and stored directly in the memory without reference to a handle

Description

DATA PROCESSOR OF MULTIPLE SUBPROCESSES The present invention relates to an apparatus for processing digital audiovisual data, in particular a decoder for a digital television system that includes a multi-threaded data processor. In PCT application PCT / EP97 / 02116, a software-based system for controlling a decoder in a digital television system using a virtual machine and a runtime machine for processing digital television data and downloaded applications is described. This system has a number of advantages compared to previously known systems for receivers / decoders, notably with respect to the independence of the application layers of the system to the hardware elements of the manufactured decoder, through the use of a machine structure virtual The system described in this application uses the principle of a single structure based on linear lists of files, to control and process events that arise in the system. With a structure based on linear lists many inconveniences are associated, including a relatively slow response to high priority events, and an inability to efficiently handle a number of concurrent entries within the system. As described, the system includes many process sequencing units. Although the system can prioritize the operation of these sequencers, once a particular process has started, it is not possible to change to another. These drawbacks of the structure become particularly acute in the case where the receiver / decoder includes an interactive application. For example, the inability of the system to change tasks in response to a priority command, combined with the often long time it takes to download data, can result in the system crashing in an operation, despite the commands part of the user to change to another mode. There is also a need to simplify the structure of the device driver of this known system. The communication between the runtime machine and the hardware level devices of the known decoder is handled by means of a plurality of device controllers, whose overall organization is managed by a device administrator, which manages the prioritization of message messages. events and their entry into the linear list structure of the process sequencing units. As described in the application, while the runtime machine is provided by means of the system authority, the controllers and the device administrator are usually provided by the decoder manufacturer, following the specifications of the system authority. In this context, the term device is usually used to refer to the interface devices that are used to process data received by, and transmitted by the decoder, such as received by means of a smart card or by means of the broadcast flow, and so on. . Differences in the interpretation of the specification by the decoder manufacturer can lead to problems where, for example, the administrator does not respect the correct classification of priority events. In that case, the linear list system will be interrupted as the events supplied to the event filter and the process sequencer are misidentified, in terms of their priority, and the linear list system will handle them incorrectly. It is an objective of one aspect of the present invention to overcome this problem. In accordance with a first aspect of the present invention, an apparatus for processing digital audiovisual data is provided, the apparatus having at least one associated hardware operating system, associated with one or more hardware devices., for the transmission and reception of data, and in which the apparatus also comprises a data processing system that includes a multi-threaded virtual machine, adapted to, inter alia, receive event messages signaled by the hardware operating system, and to assign event objects corresponding to one or more subprocesses, and in which a subprocess including an event object can be suspended, during the course of its execution, to allow execution of another subprocess. Through the use of a multi-threaded architecture, the present invention enables the system to respond effectively to the arrival of events, received through the external interfaces of the apparatus, allowing rapid treatment of high priority events, during the temporary suspension of non-urgent processes. In one modality, the virtual machine has a multi-threaded architecture by preference, in which a subprocess is suspended during the course of its execution, after the creation of a higher priority subprocess. Although this modality is preferred due to its responsiveness to priority events, other modalities can be contemplated, such as a time segmentation mode, in which the virtual machine interrupts the execution of. a subprocess at previously determined periodic intervals, to see if another subprocess exists to be executed. Preferably, the virtual machine comprises an event manager, adapted to respond to an event message signaled by the hardware operating system, by storing an event object in one or more subprocesses in a linear list of threads organized by priority . In this way, the prioritization of events can be handled directly by the virtual machine, avoiding the problems of the known system, in which events are ordered first by insertion in the linear list of the processor, by means of drivers and administrators of low-level devices. level. As described above, the implementation of a controller may vary from one manufacturer to another. In contrast, in this preferred embodiment, event messages are classified and prioritized by means of an event manager inside the virtual machine, whose characteristics can not be changed from one platform to another. Regardless of the fact that now the virtual machine can perform event handling effectively, the system can also understand, however, in certain embodiments, one or more device drivers to serve as an interface between the operating system of the virtual machine and the operating system at the hardware level. In addition to the events that arise from the hardware operating system, the event manager can also be configured to respond to event messages that arise from inside the virtual machine or from higher level applications.

In the preferred modes, you can also prioritize the order of the event objects inside a. subprocess, in accordance with the priority of the event and / or the arrival time of the event. This can be in addition to the initial prioritization performed in the assignment of instructions to subprocesses in the linear list of subprocesses. In one implementation, the virtual machine may also comprise a routing table containing information regarding possible event messages, and which may be directed by the event manager, to allow the event manager to determine the correspondence of subprocesses of a message of event received. The routing table can also be used to determine the priority of an event object inside a subprocess. As will be understood by one skilled in the art, alternative elements may also be used. In addition to an event manager and a routing table, the virtual machine also preferably comprises a scheduler adapted to examine the subprocesses contained in the linear list of threads organized by priority, and to order the execution of the subprocess that has the highest priority. high at that time. In order to implement a thread management operation by preference, the event manager can be adapted to signal the arrival of an event message, and to cause the scheduler to examine the new state of the sub-processes contained in the linear list of events. subprocesses An additional problem with the system in the PCT application PCT / EP97 / 02116 described above, relates to the processing of the received code. Although the use of the virtual machine and the runtime machine allows the system described in this application to be very independent of the hardware level of the system, the opening of the system, however, is limited by the code that is used to write the applications that are located on top of the level of the virtual machine in the known system. As described in the application, the code is written in an interpretive language, which is downloaded to the receiver from a broadcast center, and interpreted by an interpreter in the virtual machine. Although the code can be chosen to be a commercially known and standardized language, problems may arise, for example, where the receiver has to process applications written in two or more different codes. This problem can arise, for example, where the decoder is introduced in a broadcasting system in which the decoders existing in the field are adapted to receive applications written in a code different from that used in the present decoder. In that case, the operator could be forced to download a given application twice; once as it is written in the original language for the existing decoders, and once as it is written in the new code for the new decoders. As will be clear, that operation is relatively inefficient in terms of the use of bandwidth. It is an object of an additional aspect of the present invention to overcome this problem. In accordance with a second aspect of the present invention, there is provided an apparatus for processing digital audiovisual data, comprising one or more hardware devices for the transmission and reception of data, external to the apparatus, the apparatus further comprising a processing system for data including a first virtual machine adapted to, inter alia, receive the written code in an interpretive language, downloaded by means of one or more of the hardware devices, the virtual machine being adapted to distinguish between the written code in at least two interpretative languages, depending on the structure of the received code, and to pass that code to a corresponding interpreting element for interpretation and execution. By means of providing an adapted virtual machine to distinguish between received codes, together with a plurality of interpreter elements to interpret that code, the present invention avoids the problems associated with prior art systems, and enables the machine to process instructions that arrive in different interpretive languages. In this way a completely open system can be provided, both in relation to the superior application and to the lower hardware interfaces. In one modality, the virtual machine distinguishes between interpretive codes in at least two interpretive languages, based on the characteristics of a header message associated with a code module in one of the languages. In particular, the virtual machine can distinguish ** between interpretive codes, based on the presence or absence of a header message associated with a code module in one of the languages. You can think of other modalities, where the machine distinguishes between codes, based on a "flag" or other element of the code in, or at the end of a flow of the transmitted code, or in the file name of a module of the code. The present invention is particularly applicable to the situation in which one or more of the interpretive languages corresponds to an object-oriented language. In that example, the machine can examine if there is a presence of a header message associated with a limes file in that language. In order to implement the code, each interpreter element can execute the code with reference to one or more function libraries. Preferably, a common library of functions is shared by a plurality of interpreter elements, in order to reduce the amount of memory that is needed for the function libraries. Regardless of the presence of a common function library, one or more of the interpreter elements can execute the code with reference to a unique function library for that interpreter. This may be desirable, for example, where certain specialized functions are more easily executed by reference to a dedicated function library. As will be understood, the size of the system can be reduced by using function libraries common to both virtual machines, whenever possible and / or convenient. An additional problem with the system in the PCT application PCT / EP97 / 02116 described above, relates to the handling of the memory used by the system to process commands. The system described in this application depends on a device administrator to manage the memory elements. In this device all calls to memory from the virtual machine are treated equally. There is no further discussion of how the device administrator can optimize the use of memory space. The device manager is part of a layer below the virtual machine, and is implemented by the receiver / decoder manufacturer rather than the system authority. Therefore there is also a risk that the implementation chosen by the manufacturer of the receiver / decoder is less than optimal, compared to the needs of the higher level elements of the system, such as the virtual machine, designed by the system authority . It is an object of the present invention in a further aspect, to overcome some or all of these problems, and to provide an improved system for the administration of the memory inside an audiovisual apparatus. In accordance with a third aspect of the present invention, there is provided an apparatus for processing digital audiovisual data, comprising a data processing system that includes a memory and a memory manager, for allocating and storing objects in memory, and in which the memory manager allocates a first set of objects, with reference to a set of identifiers, each identifier including a reference to the address of the memory of a corresponding object, and in which a second set of objects are assigned and stored directly in the memory, without reference to an identifier. By dividing the memory between objects accessible by an identifier, and objects that can be retrieved directly, the present invention distinguishes between a first set of objects that can be treated in many ways by means of the memory manager, to optimize the space of memory, as will be described later, and those objects that are accessed more frequently, which can be addressed directly without the need to refer to an identifier. In particular, in one embodiment, an object in the second set can be retrievable directly by means of other elements in the data processing system, without the need to go through the memory manager. It may be required, however, that the memory manager distribute and store objects from the second set in memory, in order to maintain control over the contents of the memory. In one embodiment, the identifiers may be stored in the memory in question. However, other embodiments are possible in which the identifiers are stored in another memory space. The identifiers can be stored dynamically or in a static configuration. In one implementation, the memory manager is adapted to move objects of the first set inside the memory, and to change the address reference stored in the corresponding identifier, in accordance with the above. Objects can be moved, for example, when no more objects can be stored in memory. The displacement can be performed, for example, in accordance with an appropriate compaction algorithm. In this way, free memory space can be optimized, while keeping track of stored objects simply and efficiently. In order to allow access of the objects of the second type at all times, these objects are preferably non-displaceable within the memory. However, other embodiments can be imagined, where, for example, the displacement of an object of the second type would be associated with a procedure for changing the direction of the object where it occurs in the system. The present invention is particularly applicable to a modality, wherein the virtual machine has a multi-threaded architecture, of the type described in relation to the first aspect of the invention, in which a subprocess can be temporarily suspended during the course of this execution, to allow the execution of another subprocess. In that case, the multi-threaded virtual machine may preferably include a garbage collection thread, internally generated, the virtual machine acting after the execution of this subprocess, to release objects in memory not currently referenced at that time. Alternatively, or additionally, the execution of the garbage collection sub-process may also cause the virtual machine to perform the displacement of objects of the first set, in accordance with a compaction algorithm, in order to group the maximum quantity together. free memory space. The space of the memory in question may correspond to the RAM of the system, although the present invention applies equally to other memory components, such as the FLASH or EEPROM units. Although the present invention is particularly applicable to a decoder for receiving and processing digital television systems, it will be understood that the principles of the data processing system stated in this application can also be applied to other devices for handling digital audiovisual data, such as digital video recorders and the like. In the context of a decoder for a digital television broadcast, the hardware devices of the decoder may include one or all of the following: an MPEG demultiplexer together with a tuner, a serial interface, a parallel interface, a modem and one or more smart card readers. The term "receiver / decoder" or "decoder" as used herein may connote a receiver to receive signals whether encoded or uncoded, for example, television and / or radio signals, which may be broadcast or transmitted by means of of some other means. The term may also connote a decoder to decode received signals. The modes of those receivers / decoders may include an integral decoder with the receiver, for decoding the received signals, for example, in a "top box", a decoder operating in combination with a physically separate receiver, or a decoder including functions. Additional features, such as a Web browser, or a built-in decoder with other devices such as a video recorder or a television. As used herein, the term "digital transmission system" includes any transmission system for transmitting or broadcasting, for example, digital data primarily audiovisual or multimedia. Although the present invention is particularly applicable to a broadcast digital television system, the invention may also be applicable to a fixed telecommunications network for multimedia internet applications, to a closed circuit television system, and so on. As used herein, the term "digital television system" includes, for example, any satellite, terrestrial, cable, or other system.

The term MPEG used in the specific description below, refers to the data transmission standards developed by the working group of the International Standards Organization "Group of Experts in Moving Images", and in particular, but not exclusively the MPEG-2 standard developed for digital television applications, and established in the documents ISO 13818-1, ISO 13818-2, ISO 13818-3 and ISO 13818-4 ..

In the context of the present patent application, the term includes all variants, modifications or developments of the MPEG formats applicable to the field of digital data transmission. An embodiment of the present invention will now be described, by way of example only, with reference to the appended figures, in which: Figure 1 shows a global view of a digital television system. Figure 2 shows the elements of an interactive system inside the digital television system of Figure 1. Figure 3 shows the architecture of the software-based system, implemented inside the receiver / decoder of the present invention. Figure 4 shows the architecture of the virtual machine inside the system of Figure 3, which includes in particular an event manager packet, an interpretation packet and a memory packet. Figure 5 shows the structure of the interpreter that is used in the virtual machine. Figure 6 shows the handling of sub-processes inside the virtual machine. Figure 7 shows the operation of the event manager and the virtual machine scheduler. Figure 8 shows the administration of the memory concentration by the virtual machine.

DIGITAL TELEVISION NETWORK Figure 1 shows an overview of a digital television system 100, in accordance with the present invention. The invention includes a mostly conventional digital television system 200, which uses the known MPEG-2 compaction system, to transmit compressed digital signals. In more detail, the 2002 MPEG-2 compressor in a broadcast center receives a stream of digital signals (typically a stream of video signals). The compressor 2002 is connected to a multiplexer and cryptographer 2004 by means of the link 2006. The multiplexer 2004 receives a plurality of additional input signals, assembles one or more transport streams, and transmits compressed digital signals to a transmitter 2008 of the broadcast center , through the link 2010, which can, of course, take a wide variety of forms, including telecommunications links. The transmitter 2008 transmits electromagnetic signals by means of the uplink 2012, to a radio beacon of 2014 satellite response, where these are electronically processed and broadcast by means of the 2016 notional downlink to the land receiver 2018, conventionally in the form of a own dish or rented by the end user. The signals received by the receiver 2018 are transmitted to an integrated receiver / decoder 2020, owned or leased by the end user, and connected to the television set 2022 of the end user. The receiver / decoder 2020 decodes the compressed MPEG-2 signal to a television signal for the television set 2022. A conditional access system 3000 is connected to the multiplexer 2004 and the receiver / decoder 2020, and is located partially in the center of diffusion, and partially in the decoder. This allows the user to access digital television broadcasts from one or more broadcast providers. A smart card can be inserted, capable of deciphering messages related to commercial offers (that is, one or many television programs sold by the broadcaster), within the receiver / decoder 2020. Using the decoder 2020 and the smart card, the end user can buy commercial offers in any subscription mode or a mode of payment by event.

INTERACTIVE SYSTEM IN THE DIGITAL TELEVISION NETWORK An interactive system 4000, also connected to the multiplexer 2004 and the receiver / decoder 2020, and located again partially in the broadcast center and partially in the decoder, allows the end user to interact with different applications by means of a rear channel 4002 modulated-demodulated. Figure 2 shows the elements of the general architecture of the interactive television system 4000, which comprises in general four main elements: 1. An authoring tool 4004 in the broadcast center or in some other place, to allow a provider of Broadcasts create, develop, debug and test applications. 2. A server of applications and data 4006, in the broadcast center, connected to the authoring tool 4004, to allow a broadcast provider to prepare, authenticate, and format applications and data for sending to the multiplexer and cryptographer 2004, for insertion within the MPEG-2 transport stream (typically the private section thereof) to be disseminated to the end user. 3. A data processing system 4008 in the receiver / decoder, for receiving and processing downloaded applications and data, and for managing communication with the other elements of the interactive system, and hardware elements of the receiver / decoder, the system 4008 including a virtual machine with a runtime machine (RTE) implemented as executable code installed in the receiver / decoder. 4. A modulated-demodulated back channel 4002, between the receiver / decoder 2020 and the application and data server 4006, for communicating signals instructing the server 4006 to insert data and applications into the MPEG-2 transport stream at the request of the final user. You can also pass information in the other direction. The receiver / decoder 2020 includes many devices for communicating with external devices within the interactive system, such as a tuner for tuning the receiver, an MPEG demultiplexer for demultiplexing the MPEG signal, a serial interface, a parallel interface, a modem and a or two card readers, adapted for reading, for example, credit cards or subscription smart cards issued with the system. The characteristics of those devices are well known in the field of digital television systems, and will not be described here in more detail.

Similarly, the classes of interactive applications that can be provided (home banking, television shopping, computer software download) will be evident to those in the field, and will not be described in more detail. Although the architecture of the decoding system described below is particularly suitable for interactive applications, it will also be noted that the described architecture can be used in simpler non-interactive digital TV systems, such as a conventional pay TV system.

ARCHITECTURE OF THE DECODER SYSTEM Returning now to the architecture of the system inside the receiver / decoder shown in Figure 3, it will be seen that a layered architecture is used. The first layer 4100 represents the hardware operating system of the receiver / decoder. This is a real-time operating system, chosen by the manufacturer to control the hardware elements of the receiver / decoder. The operating system in real time has a relatively fast response time, in order to be able to correctly synchronize hardware operations. The message events are passed between this layer and the intermediate support layer 4200 immediately above. The data processing system 4008 sits on top of the hardware operating system, and comprises an intermediate support layer and an application layer (or more correctly, an application interface). The intermediate support layer is written in a language such as C ANSI, and comprises the elements of a virtual machine 4250, and a number of interfaces 4260, including a graphical interface 4261, a memory interface FLASH / PROM 4262, a protocol interface 4263 and a device interface 4264. As with the declared system in the PCT patent application PCT / EP97 / 02116 described in more detail in the introduction, the present invention uses a virtual machine in order to provide independence between the higher level applications and the lower level operating system. implemented by the manufacturer. The interfaces 4260 provide the link between the operations of the virtual machine and the lower-level operating system 4100, and further include a number of intermediate-level application modules that are more easily executed at this level. The application interface layer (API) 4300 comprises a number of high-level packets 4310-4314, written in an object-oriented interpretive language, such as Java. These packages provide an interface between the applications created by the service provider (interactive program guide, shopping on TV, Internet browser, etc.) and the virtual machine of the system. Subsequently, the examples of these applications are given. The lower level OS is usually embedded in the hardware components of the decoder, although in some embodiments, the lower level OS may be downloaded. The layers packages of the intermediate support interfaces and applications can be downloaded into the RAM or FLASH of the decoder, from a broadcast transmission. Alternatively, some or all of the elements of the layers of the intermediate support interfaces or applications may be stored in the ROM (if present) or FLASH of the decoder. As will be understood, the physical organization of the elements of the decoder memory is different from the logical organization of the memory.

APPLICATION INTERFACE LAYER Referring to the application interface layer 4300 shown in Figure 3, and as described above, the packets in this layer are written in an object-oriented language such as Java. Each packet defines a set of class libraries that call during the operation of the system. In the present system the following packages are installed. Language Pack / Utilities 4310. These pays define the classes necessary for the manipulation of objects by the virtual machine. These class libraries are normally part of a standard library associated with the chosen object-oriented languages. Package MHEG-5 4311. This package defines the classes associated with the manipulation of graphic objects in the visual television display. These objects are different from the audiovisual data and can form, for example, identifiers of text channels placed on visually displaced images. The definition of classes within this package must respect the MHEG-5 standards defined by the standards ETS 300777-3 and ISO / ISE 13522-5 (and the ISO / ISE 13522-6 standard, in the case of a system implemented in Java ). Toolbox Package 4312. This package contains the classes that are used for downloading and decompressing information, as well as classes associated with file system management and memory within the receiver / decoder, and classes associated with the connection to the internet, etcetera. Device Package 4313. This package defines the classes required for the administration of peripherals attached to the receiver / decoder, as described above, and which includes a modem, smart card readers, the MPEG stream tuner, and so on. Service Pack 4314. This package defines the classes required for the implementation of high-level interactive applications in development, such as the administration of credit card data, and so on. DSMCC-UU 4315 package. This package implements the necessary protocols for communication between a client and a server for searching and reading data files. The implementation of this package must respect the ISO / IEC standard 13818-6 and the guidelines defined in DAVIC part 9. Another layer of interactive applications, written by the service provider and downloaded during dissemination as in conventional systems, will be on the interface packages defined above. Depending on the applications that are going to be introduced, some of the previous packages can be omitted. For example, if the service provider does not intend to provide a common way of reading data, the DSMCC-UU package of the final system may be left out. The 4300 packages provide class libraries for an object-oriented programming environment. Your class behavior will depend on the language chosen. In the case of a Java application, for example, a single inheritance class structure will be attached.

INTERFACE LAYER As shown, the interface layer comprises four modules, a graphics module 4261, a memory file management module 4262, a protocol module 4263 and a device manager 4264. Although the modules in this Levels are described as interfaces modules, their fuon is to provide a layer of "glue" for the implementation of the application interface packets, and for the operation of the virtual machine generally. The graphics module 4261, for example, provides the creation and administration of graphic objects. This asks the low level OS to visually display basic graphic forms such as individual pixels, lines, rectangles, and so on. The implementation of this module depends on the graphics capability of the low level manufacturer's OS. In some way complementary to the package MHEG-54311, these functions can be executed more efficiently at this level of code than in the high-level code chosen for the previous application layer. In a similar manner, the 4262 memory file management module includes low-level read / write file commands associated with the system's memory components. Typically, the hardware operating system only includes the commands necessary to read / write a sector or page inside a memory component. Since they are the 4261 graphics module, this module allows a set of simpler lower level applications to be efficiently introduced into the system. The protocol management module 4263 defines a library of communication protocols that can be called in the communications medium, for example, the TCP / IP layer of the decoder. The device manager 4264 is slightly different from the other modules in this layer, in the sense that it provides the link or interface between the hardware operating system and the previous layers, including the other modules in the interface layer and the virtual machine. The commands or messages of events that are received / sent to the hardware OS from the virtual machine, for example, are necessarily passed through the device manager for conversion, in accordance with the specifications of the interface between the two levels.

DESCRIPTION OF THE VIRTUAL MACHINE Referring now to Figure 4, the structure of the virtual machine 4250 that is used in the system of the present invention will be described. The virtual machine that is used in the present invention is a machine of the multi-threaded type by preference. The general characteristics of this machine are known in other contexts outside the fields of audiovisual and digital television, and the following description will focus on those areas that are the most specific to the present application. The virtual machine is composed of a number of elements, which generally interact as shown in Figure 4. The 4270 scheduler composed of a 4271 thread administrator services, and a 4272 monitor administrator services, forms the heart of the machine of multiple threads. The 4270 scheduler orders the execution of subprocesses created by applications externally to the virtual machine, and those created by the virtual machine itself (for example, a garbage collection thread as described later). The 4273 event manager handles an event routing table, and the event lists subscribed through the subprocesses, and centralizes the dispatch of event treatments. The memory manager 4274 handles the allocation and unassignment of the memory zones within the system memory, and also handles the removal of the memory from non-referenced objects (garbage collection). The class administrator 4275 changes the classes of the downloaded application code in a broadcast signal, inter-acting with the security administrator 4280, to verify the integrity of the downloaded code, and with the file manager 4276, which implements the applications.

The 4276 file manager performs the implementation of the system files, and manages the download mechanism of the interactive applications and data. Security administrator 4280 handles the level of access allowed to downloaded applications, some applications having the ability to perform more operations than others in relation to the file system. The interpreter 4277 which comprises a service of interpreting the byte code 4278, and an interpretation service of "m code", handles the interpretation of the applications written in these two codes, the byte code being associated with the Java applications, and the code m being the name given to a proprietary code developed by the applicants. As will be described, additional interpretation services can be added if desired. The operation and implementation of the class manager, the file manager and the security administrator may be conventional. Now the description will focus on the operation of the interpreter, the scheduler and the event manager and the memory manager.

INTERPRET Referring now to Figure 5, the operation of the interpreter 4277 that is used in the embodiment of the present invention will now be described. As described in the introduction, the inconvenience of the conventional operating systems that are used in the decoders proposed to date, has been their dependence on a single type of code for high-level applications. Although the chosen system may be a commercially available and widely known application code, problems may nevertheless arise in the case where it is necessary to maintain a field of a number of decoders, using different applications written in a number of codes. The interpreter of the present system allows the interpretation of a number of types of codes. As shown, the files that arrive to the system, whether they are classes of byte codes or m-code modules, are evaluated by the class manager of module 4500, in accordance with the structure of the file, in such a way that the application code sent The interpreter 4510 has a format indication. In the case of an application of byte codes, for example, the downloaded class file will have a feature identification header of 4 octets, followed by a version number, also of 4 octets. The interpreter can distinguish between codes, based on the presence or absence of this byte code header. In other embodiments, other characteristics of the code types may be used, to distinguish between any number of application languages, such as the file name, for example.

Depending on the result of the format indicator, the instructions are sent to the byte code interpreter 4278, where these are executed with reference to a function library 4520, associated with the bytecode instructions, as is conventionally the case with the interpretive code instructions. The function library of the native code instructions is defined inside the virtual machine. In the case of the m-code instructions, these are passed to an m-code interpreter 4278. Most of the m-code instructions can be implemented and executed with reference to the 4520 function library, associated with the code instructions of the code. bytes, and the interpreter 4278 calls the library 4520 to execute those functions of the m code, whenever possible. In some circumstances, however, some m-code instructions may require specific execution functions, which can not be easily executed, with reference to a common library of functions. In those cases, it could be contemplated that the instructions are implemented with reference to a separate function library 4530.

PLANNER AND EVENT MANAGER The operation of the scheduler_4270 and the event manager 4273 will now be described, with reference to Figure 6, which shows the file of a subprocess within the system, and Figure 7 that shows the notification of an event to a subprocess, by means of the system, in response to an event signaled by the lower-level runtime operating system. The description will focus on the management of the creation of a subprocess that represents an execution context, which is the particular result of a signalized event. It will be understood that a subprocess can be created with the start of a command generated by a higher level application, to be sent to the hardware OS and by the return of this command. You can also create a subprocess inside the virtual machine itself, for example, a garbage collection thread. As mentioned above, the present modality depends on a "virtual machine that handles subprocesses by preferences, such as the one that is found in Java-based systems." On that machine, a plurality of subprocesses are generated, and stored in a list Thread Linear - The scheduler inspects the linear thread list and selects the thread with the highest priority to be executed Normally, the thread that is running has the highest priority, but that thread can be interrupted by a thread. subprocess of an even higher priority, as is conventional in thread systems by preference, in which case the state of the interrupted thread is stored, and the thread is reactivated once it is selected again to be executed. , a subprocess can itself include an instruction called "produce", which causes the scheduler to suspend the execution of the s ubprocess, and inspect the linear list of threads to see if there is another thread to execute. The production instruction may be present in internally generated low priority tasks, such as a garbage collection function performed by the system, in order to remove unused objects from the system memory. Figure 6 shows these aspects of the system. The creation of a thread at 4550 gives rise to a thread stored in the linear list of threads 4551. The newly created thread has the status "init" at 4552. If no other thread has a higher priority, the thread is executed by means of a sub-process. the start () statement, and it will have the "executable" state at 4553. If the stop () statement is executed on the thread, the thread "dies" at 4554. The thread can also get this state if it is terminated as indicated by means of the instruction run () fini. If a yield () statement occurs on the same thread, or if a suspend command is executed external to the thread, the thread is suspended and given the "non-executable" state at 4556.

Referring now to Figure 7, the interaction between the lower-level operating system 4100, the event manager 4273 and the 4270 scheduler will now be described. The unprocessed events, signaled by the runtime operating system 4100, are passed through means of the device manager 4313 to the event manager 4273, in a preferred embodiment, the device manager 4313 and / or the multi-tasking system that is used in the operating system 4100 can perform some prioritization of the received events. However, as will be clear, one of the advantages of the present system lies in the fact that, unlike the system described in PCT / EP97 / 02116, the management of the events is managed inside the virtual machine 4250, enabling in this way the creator of the intermediate support layer to obtain full control over the event handling procedure. In the present modality, the events sent through the device manager 4313 are classified by their code and their type. The code identifies the characteristics of the event, for example, in the case of an event generated through the operation of a remote control associated with the decoder, the code can identify the button, pressed. The type identifies the origin of the event, for example, the remote control. After receipt of an event signal, the event manager 4273 uses a routing table 4560 to determine the priority of the event and the destination of the thread, and inserts a corresponding event object 4564 into one or more subprocesses 4561 located inside of the linear list of threads 4562 based on priority. One or more 4564 event objects can be stored inside of one. given thread, as represented by 4563. Event objects 4564 are stacked inside the subprocess, in accordance with their priority classification. The event objects inside the thread of an equal priority are classified by their arrival time (FIFO). Upon receipt of an event, the event manager 4273 signals its arrival to the 4270 scheduler, which then examines the linear thread list to see if a subprocess has a higher priority than the currently executing thread. If so, then the current thread is suspended, as described above, and the new thread is executed. In this way, a system that handles subprocesses by preferences is implemented. . In this way, the preferred modality allows the efficient management of the subprocesses in the decoder, in order to allow the system to respond quickly to the calls of events, even in the case in which the system is processing an existing previous event. By the same, the inconveniences of the linear list system of the individual processor are overcome. Although the preferred embodiment has been described in relation to a system by preference, in which the arrival of an event causes the event manager to signal the scheduler to interrupt the execution of a subprocess, other implementations are possible. For example, in a time segmentation system, the scheduler may periodically interrupt the execution of a subprocess to examine the state of the linear thread list. Alternatively, the scheduler can be adapted to interrupt the execution of a subprocess, to examine the linear list of subprocesses after each instruction in which the subprocess is treated.

MEMORY ADMINISTRATOR _. As will be noted, in the context of the receiver / decoder, the management of the memory concentration within the system is particularly important, since the memory space is relatively restricted compared to, for example, a PC or other platform based on HDD. In the following description, the memory concentration corresponds to the memory space inside the RAM of the receiver / decoder. Nevertheless, as mentioned above, the correspondence between the physical and logical organization of the memory is not exact, and the concentration of memory described below could be located in, or shared among other physical memory devices, such as a FLASH memory, a EEPROM, etc., inside the receiver / decoder. Referring now to Figure 8, this shows the organization of the available memory in the system. It will be seen that the memory space is shared between a concentration of identifiers 4600, a concentration of displaceable objects 4610, and a concentration of non-displaceable objects 4620. Each object in the concentration 4610 is identified by means of, and corresponds to a identifier stored in the 4600 concentration. The relationship between an identifier and its corresponding object is administered by the memory management package 4274 (see Figure 4), which also controls access to the concentration. All calls to the objects in the concentration are made by means of their identifier. The limit between the concentrations 4600 and 4610 is mobile. When a new object is to be stored in the memory, an identifier is created in the concentration 4600, which includes a pointer to the address of the object inside the 4610 concentration. In that case, the list of identifiers will be increased by one. The identifiers are organized in a list formation in the concentration, to allow compaction by means of the memory manager. The objects will be assigned in the concentration as needed, and in accordance with the space available. In the event that an assignment of objects requiring more space in a block is demanded, than it is available, it will be necessary to compress the objects already assigned in the memory. The compacting of the objects in the memory can be done in accordance with any known compaction algorithm, for example, a copy compaction algorithm. In the present modality, the Mark Sweep compaction algorithm is used. In order to compact the space, the objects move around in the area 4610, in order to group the objects closer together, avoiding any spaces between adjacent objects. In this way, all the free memory space is grouped together in a block, with the object of assigning for a new object in the 4610 concentration. As mentioned above, the memory management package maintains the correspondence between the identifiers in the 4600 concentration and the objects in the 4610 concentration, and the new addresses of the objects in the concentration will be updated to the new identifiers for future access. - **** - * - Although the use of identifiers to access certain objects allows the system to optimize the location of memory in the concentration, the process increases the time it takes to access those objects, since it is always necessary to recover first the identifier, in order to find the address of the object. In certain situations, and for objects that correspond to certain designated events, a faster access time may be required. In that case, the objects can be assigned in a concentration of non-displaceable objects 4620. The direction of those objects is fixed inside the concentration. In this way there is no need for the creation of an identifier, and the system directly uses the objects, thereby simplifying the access procedure for these special objects. Again, as with the limit between the 4600 and 4610 concentrations, the limit between the 4620 and 4610 concentrations will be changed, depending on the information stored in the 4620 concentration. In the case that, for example, a non-displaceable object is assigned to concentration 4620, and there would not be enough space due to the configuration of the displaceable objects in the concentration _4S1Q, a compaction of the movable objects can be carried out, as described above. Once the objects in the concentration are rearranged, in order to release the maximum amount of space, then it would be possible to assign a non-displaceable block in the concentration 4620. The choice of which objects are displaceable and which objects are non-displaceable It is at the discretion of the designer. For example, the objects that correspond to the system can be selected as non-scrollable, in view of the importance of these objects, while the objects of high-level applications can be scrollable. In certain cases, the movable objects can be temporarily locked in place, in order to be considered as non-mobile objects. In order to eliminate objects from the concentration of memory, the system may also include a so-called garbage collection. This involves the creation of a special garbage collection thread of the lowest priority, which will direct the scheduler in case no other thread is currently stored in the linear list. After the execution, all the displaceable objects assigned at that moment in the concentration, which are not being referenced at that moment, will be released. The garbage collector thread can also perform the compaction of all other moveable objects along the lines described above. The creation of a garbage collection subprocess is known in the context of other multi-threaded systems that are used in other applications outside of a digital television system, and will not be described in more detail herein. However, it will be noted that the use of a garbage collection procedure, in combination with the other memory management techniques described above, provides particular advantages in the present context.

Claims (37)

1. An apparatus for processing digital audiovisual data, the apparatus having at least one associated hardware operating system, associated with one or more hardware devices, for transmitting and receiving data, and wherein the apparatus also comprises a data processing system. data that includes a multi-threaded virtual machine, adapted to, inter alia, receive messages from events signaled by the hardware operating system, and to assign event objects corresponding to one or more subprocesses, and in which a subprocess can be suspended during the course of its execution, to allow the execution of another subprocess.

An apparatus, as claimed in claim 1, wherein the virtual machine has a multi-threaded architecture by preference, in which a subprocess is suspended during the course of its execution, by creating a priority subprocess highest.

An apparatus, as claimed in claim 1 or 2, wherein the virtual machine comprises an event manager, adapted to respond to an event message signaled by the hardware operating system, by means of storing an object of event in one or more subprocesses in a linear list of subprocesses organized by priority.

4. An apparatus, as claimed in claim 3, in which the event messages sent from the hardware operating system to the event manager are first processed by one or more device administrators, inside the processing system of data .

5. An apparatus, as claimed in claim 3 or 4, wherein the event manager is also adapted to respond to an internally generated event message by means of the virtual machine, or received from a high-application level inside or outside the data processing system.

An apparatus, as claimed in any of claims 3 to 5, wherein the event manager classifies the event objects internally within a subprocess, in accordance with the priority of the event message and / or the time of the event. arrival of the event message.

An apparatus, as claimed in any of claims 3 to 6, wherein the virtual machine further comprises a routing table containing information regarding possible event messages, and the event administrator can direct it, to allow that the event manager determines the correspondence of subprocesses of a received event message.

8. An apparatus, as claimed in claim 7, wherein the routing table contains information to enable the event manager to determine the priority of an event object within a subprocess.

9. An apparatus, as claimed in any of claims 3 to 8, wherein the virtual machine further comprises a scheduler adapted to examine the subprocesses contained in the linear list of sub-processes organized by priority, and to order the execution. of the subprocess that has the highest priority at that time.

An apparatus, as claimed in claim 9, wherein the event manager is adapted to signal the arrival of an event message, and to cause the scheduler to examine the new state of the subprocesses contained in the linear list of threads.

11. An apparatus for processing digital audiovisual data, comprising one or more hardware devices for the transmission and reception of data, external to the apparatus, the apparatus further comprising a data processing system that includes a first virtual machine adapted for, inter alia, receive the written code in an interpretive language, downloaded by means of one or more of the hardware devices, said virtual machine being adapted to distinguish between the written code in at least two interpretive languages, depending on the structure of the received code, and to pass that code to a corresponding interpreter element for interpretation and execution.

12. An apparatus, as claimed in claim 11, wherein the virtual machine distinguishes between interpretive codes in at least two interpretive languages, based on the characteristics of a header message associated with a code module in one of the languages .

13. An apparatus, as claimed in claim 11 or 12, wherein the virtual machine distinguishes between interpretive codes, based on the presence or absence of a header message associated with a code module in one of the languages.

14. An apparatus, as claimed in any of claims 11 to 13, wherein at least one of the languages is an object-oriented language.

15. An apparatus, as claimed in any of claims 11 to 14, wherein the virtual machine identifies the code written in an object-oriented language, by means of the presence of a header message associated with a class file in that language

16. An apparatus, as claimed in any of claims 11 to 15, wherein each interpreter element executes the code with reference to one or more function libraries.

17. An apparatus, as claimed in claim 16, wherein a library of functions * shares a plurality of interpreter elements.

18. An apparatus, as claimed in claim 16 or 17, wherein one or more of the interpreter elements executes the code with reference to a function library unique to that interpreter element.

19. An apparatus for processing digital audiovisual data, comprising a data processing system including a memory and a memory manager, for allocating and storing objects in memory, and in which the memory manager allocates a first set of data. objects, with reference to a set of identifiers, each identifier including a reference to the address of the memory of a corresponding object, and in which a second set of objects are assigned and stored directly in the memory, without reference to an identifier.

An audiovisual apparatus, as claimed in claim 19, wherein the objects in the second set are allocated and stored in the memory by means of the memory manager, but can be retrieved directly by * means from other elements of the system of data processing.

21. An audiovisual apparatus, as claimed in claim 19 or 20, wherein the set of identifiers are also stored in the memory.

22. An audiovisual apparatus, as claimed in any of claims 19 to 21, wherein the memory manager is adapted to move objects of the first set inside the memory, and to change the address reference stored in the corresponding identifier , in accordance with the above.

23. An audiovisual apparatus, as claimed in claim 22, in which the objects of the first set are moved inside the memory by means of the memory manager, when no more objects can be stored in the memory without the movement of the memory. the existing stored objects.

24. An audiovisual apparatus, as claimed in claim 22 or 23, wherein the objects of the first set are moved in accordance with a compaction algorithm, in order to group together the maximum amount of free memory space inside of the memory, as calculated by means of the compaction algorithm.

25. An audiovisual apparatus, as claimed in any of claims 19 to 24, wherein the objects of the second set are non-displaceable within the memory.

26. An audiovisual apparatus, as claimed in any of claims 19 to 25, wherein the data processing system includes a virtual machine, the memory manager forming part of the virtual machine.

27. An audiovisual apparatus, as claimed in claim 26, wherein the virtual machine has a multi-threaded architecture, in which a subprocess can be temporarily suspended during the course of this execution, to allow the execution of another subprocess .

28. An audiovisual apparatus, as claimed in claim 27, wherein the multi-threaded virtual machine includes a garbage collection thread, internally generated, the virtual machine acting after the execution of this subprocess, to free objects in the memory not currently referenced at that time.

29. An audiovisual apparatus, as claimed in claim 28, wherein the execution of the garbage collection sub-process also causes the virtual machine to perform the displacement of objects of the first set, in accordance with a compaction algorithm, with the object of grouping together the maximum amount of free memory space.

30. An audiovisual apparatus, as claimed in any of claims 19 to 29, wherein the memory is defined by one or more RAM components.

31. An apparatus, as claimed in any of the preceding claims, wherein the apparatus is a decoder for a digital transmission system, such as a digital television system.

32. An apparatus, as claimed in any of claims 1 to 18, wherein one of the hardware devices comprises an MPEG demultiplexer.

33. An apparatus, as claimed in any of claims 1 to 18, wherein the hardware devices can comprise at least one of the following: a tuner, a serial interface, a parallel interface, a modem and one or more smart card readers.

34. An apparatus for processing digital audiovisual data, comprising: a hardware operating element associated with one or more hardware devices for data transmission and reception; and a multi-threaded virtual machine comprising an element for receiving messages from events signaled by the hardware operating element, an element for assigning event objects corresponding to one or more subprocesses, and an element for suspending a subprocess during the course of its execution, to allow the execution of another subprocess.

35. An apparatus for processing digital audiovisual data comprising one or more hardware devices for the transmission and reception of external data to the apparatus., and a virtual machine that comprises an element to receive codes written in an interpretive language downloaded by means of one or more of the hardware devices, an element to distinguish between the written code in at least two interpretative languages, depending on the structure of the received code, and an element to pass said code to a corresponding interpreter element for interpretation and execution.

36. An apparatus for processing digital audiovisual data, comprising a memory and a memory manager comprising an element for assigning a first set of objects, with reference to a set of identifiers, each identifier including a reference to the address of the memory of a corresponding object, and an element to assign and store a second set of objects, directly in the memory, without reference to an identifier.

37. An apparatus for processing digital audiovisual data, substantially as described herein.