BR112014014592B1

BR112014014592B1 - Processo de troca de mensagens entre tarefas clientes de um mesmo barramento de software

Info

Publication number: BR112014014592B1
Application number: BR112014014592-0A
Authority: BR
Inventors: Antonie Rocquelay; Laurent Alarcon
Original assignee: Sagemcom Broadband Sas
Priority date: 2011-12-16
Filing date: 2012-12-14
Publication date: 2021-08-24
Also published as: US9052951B2; FR2984554A1; CN104081355B; BR112014014592A2; EP2791798A1; CN104081355A; FR2984554B1; WO2013087894A1; EP2791798B1; US20140373017A1

Abstract

barramento de software. a presente invenção refere-se ao domínio dos processos de comunicação entre módulos de software e mais particularmente dos barramentos de software. é descrito um barramento de software que permite a comunicação entre módulos de software. essa comunicação intervém no meio de uma máquina e entre máquinas, e funciona indiferentemente para um módulo de software quer se trata de uma linha ou de uma simples tarefa. a comunicação se baseia em mecanismos adaptados ao nível de multitarefa no qual funcionam os módulos de software emissores e receptores. ele é baseado em uma arquitetura hierárquica, das fases de descobertas e de registros dos diferentes módulos de software que devem se comunicar junto ao barramento.

Description

[001] A presente invenção refere-se ao domínio dos processos de comunicação entre módulos de programas e, mais particularmente, barramentos de software.

[002] Os dispositivos de tratamento da informação funcionam sob o controle de um sistema de exploração. Esses sistemas de exploração são multitarefas e permitem programar uma pluralidade de módulos de software. Esses módulos de software podem ser de vários tipos, em função do programador (scheduler, em inglês) que organiza a mul- titarefa e possibilidades de uma hierarquia de módulos.

[003] Historicamente, os sistemas de exploração permitiram pro gramar linhas. Uma linha se define como um módulo software, dispondo-se de seu próprio controle e de seu próprio espaço memória. A programação das linhas é efetuada tipicamente hoje de maneira preempetiva. Isto é, o programador decide, de maneira arbitrária, os momentos de oscilação de contexto entre as linhas. O contexto da linha corrente, tipicamente o conteúdo de controle, é então protegido. Uma outra linha em espera é selecionado, seu contexto é restaurado. Ele pode, então, continuar sua execução.

[004] A oscilação de contexto é uma linha relativamente dupli cada. A necessidade de movimentar, em paralelo, módulos de software em linha surgiu. Criou-se, portanto, a noção de linhas (thread, em inglês). Tipicamente, um conjunto de linhas é programado no meio de um espaço memória comum, trata-se geralmente de uma linha.

[005] Em determinados casos, pode-se implementar um nível su plementar e programar um conjunto de tarefas mesmo no meio de uma linha. A programação pode então ser preemptiva ou não. A outra família de programação, a programação cooperativa fazendo-se na ocasião de chamadas de sistemas explícitos nas quais a tarefa passa o controle explicitamente ao programador. A diferença principal se refere ao fato de, nessa programação, uma tarefa que entra em um circuito infinito pode impedir que o sistema retome a mão e bloqueie o sistema completo. A vantagem sendo que, uma tarefa podendo não se encontrar interrompida a qualquer momento, não é necessário proteger os recursos divididos por mecanismos de exclusão mútua (mutex, em inglês).

[006] Considera-se, portanto, o software executado sobre um dispositivo de tratamento de informação, como uma ou várias linhas, cada linha podendo ser ele própria constituída de uma ou várias linhas, cada linha podendo ser constituída de uma ou várias tarefas. A programação das linhas e das linhas será considerada como preemp- tiva, aquela das tarefas podendo ser preemptiva ou não. Utilizamos o termo módulo de software para designar o conjunto dessas linhas, linhas e tarefas de maneira genérica.

[007] Essa hierarquia de módulos de software é ilustrada pela figura 1. É visto aí um dispositivo de tratamento da informação 1.1. Esse dispositivo permite a execução em paralelo de três linhas 1.2, 1.3 e 1.4. Essas linhas são programadas pelo sistema de exploração 1.16. A linha 1.2 contém várias linhas 1.5, 1.6, 1.7 e 1.8 executados em paralelo, programadas pelo sistema de exploração 1.16. A linha 1.3 não contém linhas. A linha 1.4 contém uma primeira linha 1.9 e uma segunda linha 1.10. Essa segunda linha 1.10 contém ela própria várias tarefas 1.11, 1.12 e 1.13 executadas em paralelo sob o controle de um programador 1.14 ele próprio executado no meio da linha 1.10. O dispositivo dispõe pelo menos de um porto de comunicação 1,.15, permitindo a comunicação com outros dispositivos via uma rede de comuni-cação, tipicamente uma rede IP.

[008] Quando se procura fazer comunicar módulos de software, encontram-se, na técnica anterior, soluções dedicadas a um nível de paralelismo determinado. As tecnologias principais sendo dedicadas à comunicação entre linhas. Podem-se citar as filas de espera de mensagens (message queue, em inglês), os sockets UNIX para uma comunicação entre linhas de um mesmo dispositivo, os sockets INET para a comunicação entre linhas situadas sobre dispositivo distantes conectadas a uma rede de tipo IP (Internet Protocol, em inglês). Existem também tubos (pipe, em inglês), nomeados ou não. Existem barramen- tos de softwares, tais como o D-barramento que é um sistema de comunicação entre linhas. Ele não é adaptado para módulos de software, tais como as simples tarefas, nem para as linhas, nem para a comunicação entre máquinas.

[009] A invenção visa propor um sistema de comunicação ou bar- ramento de software que permita a comunicação entre módulos de software. Essa comunicação intervém no meio de uma máquina e entre máquinas e funciona indiferentemente para o módulo de software quer se trate de uma linha, de uma linha ou de uma simples tarefa. A comunicação se baseia em mecanismos adaptados no nível de multi- tarefas no qual funcionam os módulos para softwares emissores / receptores. Ele é baseado em uma arquitetura hierárquica, fases de descobertas e de registro dos diferentes softwares que devem se comunicar junto do barramento.

[0010] A presente invenção refere-se, portanto, a um dispositivo de tratamento de informação que comporta:

[0011] - um sistema de exploração;

[0012] - pelo menos uma linha programada por esse sistema de exploração, e

[0013] - linhas que podem ser programadas no meio dessas linhas por esse sistema de exploração. Ele é caracterizado pelo fato de com- portar, além disso:

[0014] - no meio de cada linha, pelo menos uma tarefa do usuário ou uma tarefa do sistema;

[0015] - cada linha contendo ela própria uma FIFO para cada tare fa que essa linha contém, assim como um módulo de gestão de bar- ramento de tipo linha, integrando ela própria um programador proprietário para a programação da(s) tarefa(s) dessa linha;

[0016] e pelo fato de para que uma primeira tarefa possa transmitir uma mensagem a uma segunda tarefa, ele comporta:

[0017] - meios para pesquisar a linha da qual essa segunda tarefa depende; e

[0018] - meios para, se essa segunda tarefa pertencer à mesma linha que essa primeira tarefa, postar essa mensagem na FIFO dedicada a essa segunda tarefa, a fim de que ela possa considerá-la;

[0019] - meios para, se a segunda tarefa pertencer a uma outra linha que a linha da qual depende essa primeira tarefa,

[0020] - criar uma tarefa relé distante no meio de uma linha dessa linha, da qual depende a segunda tarefa;

[0021] - criar uma tarefa relé no meio de uma linha dessa linha, da qual depende a primeira tarefa;

[0022] - criar uma conexão entre a linha, da qual depende a pri meira tarefa e a linha da qual depende a segunda tarefa;

[0023] - postar essa mensagem na FIFO dedicada a essa tarefa relé;

[0024] - transmiti-la à tarefa relé distante via essa conexão;

[0025] - postá-la na FIFO da segunda tarefa, a fim de que ela pos sa considerá-la.

[0026] Vantajosamente, os meios para pesquisa da linha, das quais essa segunda tarefa depende, são constituídos de módulos de gestão de barramentos associados a cada linha, cada um desses mó- dulos de gestão de barramentos comportando uma mesa de rotea- mento listando as tarefas e as linhas dessa linha, da qual elas dependem.

[0027] Vantajosamente, os meios para transmitir uma mensagem entre essa tarefa relé e essa tarefa relé distante são constituídos, para cada linha, de um módulo de comunicação interlinhas hospedado por uma linha dessa linha.

[0028] Vantajosamente, esse dispositivo de tratamento de infor mação comporta meios para inicializar uma dessas linhas enquanto essa linha mestre, e as outras linhas, enquanto linhas escravas. A linha mestre comporta um módulo de comunicação interdispositivo hospedado por uma linha dessa linha, de maneira a poder transmitir uma mensagem, entre uma tarefa relé desse dispositivo e uma tarefa relé distante hospedada em um outro dispositivo de tratamento de informação.

[0029] A invenção refere-se também a um processo de troca de mensagens entre tarefas que se desenrolam em um ou dois dispositivos de tratamento de informação, tal como acaba de ser descrito. Essa linha é caracterizada pelo fato de, para transmitir uma mensagem de uma primeira tarefa à segunda tarefa, ele comporta:

[0030] - as seguintes etapas utilizadas pelo módulo de gestão de barramento de linha hospedando essa primeira tarefa:

[0031] - quando essa segunda tarefa pertence à mesma linha que essa primeira tarefa, uma etapa de postagem dessa mensagem na FIFO dedicada a essa segunda tarefa, a fim de que esta possa considera-la, caso contrário

[0032] - uma etapa de transmissão a esse módulo de gestão de barramento da linha mestre de uma mensagem de pesquisa da segunda tarefa;

[0033] - as etapas seguintes utilizadas pelo módulo de gestão de barramento da linha mestre:

[0034] - quando essa segunda tarefa é hospedada por uma linha da linha mestre;

[0035] - uma etapa de criação de uma tarefa relé distante no meio de uma linha dessa linha mestre;

[0036] - uma etapa de transmissão de uma resposta a esse módu lo de gestão de barramento da linha que hospeda a primeira tarefa;

[0037] - caso contrário,

[0038] - uma etapa de difusão a cada um desses módulos de ges tão de barramento de tipo linha uma mensagem de busca da segunda tarefa;

[0039] - as etapas seguintes utilizadas pelo módulo de gestão de barramento de uma linha escrava que hospeda a segunda tarefa, com recebimento de uma mensagem de pesquisa da segunda tarefa;

[0040] - uma etapa de criação de uma tarefa relé distante no meio de uma linha dessa linha escrava;

[0041] - uma etapa de transmissão de uma resposta a esse módu lo de gestão de barramento da linha mestre;

[0042] - a etapa utilizada, além disso, pelo módulo de gestão de barramento da linha mestre, em sequência ao recebimento da resposta transmitida pelo módulo de gestão de barramento da linha escrava, de transmissão de uma resposta a esse módulo de gestão de barra- mento da linha que hospeda a primeira tarefa; e

[0043] - as etapas seguintes utilizadas pelo módulo de gestão de barramento da linha que hospeda essa primeira tarefa, quando ele tiver recebido uma resposta desse módulo de gestão de barramento da linha mestre:

[0044] - uma etapa de criação de uma tarefa relé correspondente a essa tarefa relé distante no meio de uma linha dessa linha que hospeda essa primeira tarefa; e

[0045] - uma etapa de postagem dessa mensagem na FIFO dedi cada a essa tarefa relé, a qual a transmitirá à tarefa relé distante, depois à segunda tarefa.

[0046] De acordo com uma outra característica vantajosa da in venção, esse processo comporta as seguintes etapas de inicialização desse barramento:

[0047] - uma etapa na qual os módulos de gestão do barramento das linhas escravas estabelecem um enlace de conexão com o módulo de gestão do barramento da linha mestre;

[0048] - uma etapa na qual cada tarefa cliente do barramento se registra junto ao módulo de gestão do barramento do qual ele depende;

[0049] - uma etapa de criação de uma FIFO associada a cada ta refa cliente do barramento e a cada módulo de gestão do barramento;

[0050] - uma etapa na qual o módulo de gestão do barramento de uma linha escrava que recebe registros de módulos de softwares clientes do barramento exporta esses registros para o módulo de gestão do barramento da linha mestre.

[0051] De acordo com uma outra característica vantajosa da in venção, essas etapas de inicialização comportam, além disso, uma etapa de criação no meio da linha mestre de tantas tarefas relés quanto forem as tarefas clientes do barramento no meio de linhas escravas no dispositivo.

[0052] De acordo com uma outra característica vantajosa da in venção, as tarefas clientes do barramento são registradas com modo público ou privado, só as tarefas públicas sendo exportadas para a linha mestre.

[0053] De acordo com uma outra característica da invenção, esse processo comporta, além disso, uma etapa de descoberta entre máquinas que participam do barramento. Essa etapa de descoberta entre máquinas que participam do barramento compreende, por exemplo:

[0054] - uma etapa de anúncio onde cada máquina que participa do barramento emite um anúncio na rede de comunicação que liga essas máquinas;

[0055] - uma etapa de recebimento de uma mensagem de anúncio proveniente de uma máquina distante;

[0056] - uma etapa de acréscimo da máquina na origem da men sagem de anúncio recebida em uma mesa, caso ela já não seja conhecida;

[0057] - uma etapa de estabelecimento de uma conexão com essa máquina distante.

[0058] As características da invenção mencionada acima, assim como outras aparecerão mais claramente com a leitura da descrição seguinte de um exemplo da érea, essa descrição sendo feita em relação com os desenhos anexados, dentre os quais:

[0059] - a figura 1 ilustra os diferentes tipos de módulos de softwa res que podem executar sobre uma máquina;

[0060] - a figura 2 ilustra a arquitetura de software do barramento em um modo de realização da invenção;

[0061] - a figura 3 ilustra a fase de inicialização do barramento no meio de uma máquina;

[0062] - a figura 4 ilustra a fase de descoberta entre máquinas que participam no barramento;

[0063] - a figura 5 ilustra a troca de mensagens entre dois módulos de softwares clientes do barramento que dependem de um mesmo módulo de gestão do barramento;

[0064] - a figura 6 ilustra a troca de mensagens entre dois módulos software clientes do barramento que não dependem do mesmo módulo de gestão do barramento, mas são hospedados no meio de uma mesma linha;

[0065] - a figura 7 ilustra a troca de mensagens entre dois módulos softwares clientes do barramento hospedados só em linhas diferentes, até mesmo máquinas diferentes;

[0066] - a figura 8 ilustra a arquitetura de um dispositivo de trata mento da informação, conforme um modo particular de utilização; e

[0067] - a figura 9 representa um diagrama, mostrando as diferen tes etapas de um processo, conforme a invenção.

[0068] A figura 2 ilustra a arquitetura de software do barramento em um modo de realização da invenção. A invenção se baseia em duas arquiteturas de linhas possíveis no meio de um dispositivo de tratamento da informação 2.1. A linha 2.2 ilustra a primeira arquitetura possível. Nessa arquitetura, um primeiro módulo software de gestão do barramento 2.4 permite a um ou vários módulos softwares 2.6, 2.7 e 2.8 se comunicar com o barramento. Esses módulos softwares destinados a se comunicarem com o barramento são denominados módulos clientes do bar. Esses módulos softwares são tipicamente linhas programadas em paralelo no meio da linha. O módulo de gestão do barramento 2.4 é também tipicamente uma linha. Essas linhas são então programadas pelo sistema de exploração no meio da linha. Essa programação é tipicamente preemptiva. Alternativamente, um progra-mador ad hoc no meio da linha pode programar esses módulos softwares que são então qualificados de tarefas executadas em paralelo no meio da linha. Sua programação pode então ser preemptiva ou não. O programador ad hoc pode ser confundido com o módulo de gestão do barramento 2.4 ou um módulo independentemente não representado conforme os modos de realização.

[0069] Na linha 2.3, encontra-se uma linha 2.5 destinada à gestão do bar para a linha. A linha 2.9 é uma linha cliente do bar. Ao contrário, a linha 2.10 não é uma cliente direta do barramento. Ela hospeda um módulo de gestão de barramento 2.11 interno à linha e uma ou várias tarefas 2.12, 2.13 e 2.14. São então estas tarefas que são as clientes do barramento. Essas tarefas são programadas no meio da linha 2.10 por um programador ad hoc que pode se confundir com o módulo de gestão do barramento 2.11 ou não.

[0070] O software é, portanto, dividido em linhas 2.2, 2.3. Cada linha contém um módulo de gestão do barramento 2.4, 2.5. Ele hospeda também um ou vários módulos softwares clientes do barramento 2.6, 2.7, 2.8 e 2.9. Esses clientes do barramento podem ser linhas ou tarefas executadas diretamente no meio da linha. Esses clientes podem compreende também tarefas 2.12, 2.13 e 2.14 executadas no meio de uma linha. A linha hospeda então também um módulo de gestão do barramento 2.11.

[0071] A fase de inicialização do barramento no meio de uma má quina se passa da seguinte forma ilustrada pela figura 3. Os módulos softwares clientes que devem se comunicar com o barramento são repartidos no meio de uma ou varias linhas. Uma dessas linhas é eleita linha mestre. As outras linhas, se existirem, serão, portanto, linhas escravas.

[0072] Quando de uma etapa 3.1, os módulos de gestão do bar- ramento das linhas escravas estabelecem um enlace de conexão com o módulo de gestão do barramento da linha mestre. Tipicamente, esse enlace de conexão é um socket UNIX.

[0073] Quando de uma etapa 3.2, cada módulo de software cliente do barramento se registra junto deste. Esse registro ocorre junto do módulo de gestão do barramento da linha ou da linha da qual depende o módulo software cliente. Vantajosamente esse registro compreende o nome do módulo software, uma referência sobre o módulo de gestão do barramento, do qual depende esse módulo software cliente, assim como um modo de visibilidade. O modo de visibilidade compreende um modo privado, no qual um módulo software cliente do barramento pode emitir uma mensagem para outros clientes públicos e receber uma resposta ligada a este sobre o barramento, mas para receber mensagens diretas dos outros clientes públicos. Ele compreende também um modo público no qual o módulo software cliente do barramen- to torna público seu nome e seu local, e pode, portanto, receber mensagens além de emiti-las.

[0074] Quando da etapa 3.3, para cada módulo de software cliente do barramento que se registra, um módulo de gestão do barramento cria uma FIFO (First In First Out em inglês) utilizada no caso de uma troca sobre o mesmo módulo de gestão do bar. Essas FIFO podem ser FIFO simples, isto é, não protegidas por uma exclusão mútua, se o sequenciamento do módulo de gestão do barramento e dos clientes do barramento sob sua responsabilidade é cooperativo. Caso contrário, utilizam-se FIFO protegidas por um mecanismo de exclusão mútua, cada módulo de gestão do barramento possui uma FIFO utilizada no caso de trocas com um módulo de gestão do barramento diferente para gerar os recebimentos de mensagens ligadas a esse módulo cliente.

[0075] Quando de uma etapa 3.4, o módulo de gestão do barra- mento de uma linha escrava que recebe registros de módulos clientes do barramento exporta esses registros para o módulo de gestão do barramento da linha mestre. Esse módulo de gestão do barramento mantém uma mesa, dita mesa de roteamento dos usuários, módulos softwares clientes do barramento presentes na máquina. Os usuários sendo no caso os módulos clientes do barramento. Vantajosamente, só os módulos que se declararam públicos estão presentes nesta mesa.

[0076] Quando de uma etapa 3.5, o módulo de gestão do barra- mento da linha mestre inicia no meio da linha mestre tantos módulos de softwares quantos forem os módulos de softwares cliente do bar- ramento no meio da linha escrava no dispositivo. Esses módulos de softwares são gerados pelo módulo de gestão do barramento da linha mestre e são denominados módulos softwares relé (proxy em inglês). Essa etapa é opcional. As linhas relés podem ser alternativamente criadas conforme a necessidade, quando das trocas de mensagens, conforme será descrito depois.

[0077] Essa fase de iniciação do barramento no meio do dispositi vo constitui, portanto, uma fase de descoberta interna, na qual as diferentes linhas no meio do dispositivo estabelecem uma comunicação com a linha eleita como mestre e onde cada módulo software cliente do barramento no meio do dispositivo é descoberto pelo módulo de gestão do barramento da linha mestre que mantém uma mesa de todos os clientes do barramento no meio do dispositivo.

[0078] A inicialização do barramento compreende vantajosamen te, além disso, uma etapa de descoberta entre máquinas que participam no barramento. Essa etapa é ilustrada pelo organograma da figura 4. Ela é utilizada para cada dispositivo pelos módulos de gestão do barramento das linhas mestres.

[0079] Quando de uma etapa de anúncio 4.1, cada dispositivo emi te um anuncio sobre a rede de comunicação, ligando os dispositivos. Vantajosamente, essa emissão é efetuada sobre os enlaces LAN em modo de difusão geral (broadcast em inglês) sobre a sub-rede deste e sobre os enlaces WAN em modo de difusão multiponto (multicast em inglês) sobre um grupo particular. Vantajosamente, essa emissão é repetida no tempo para permitir a novas máquinas, que se conectam ao barramento, descobrir as máquinas existentes. A mensagem de anúncio contém vantajosamente o nome da máquina, assim como seu endereço IP e um porto para permitir uma conexão IP.

[0080] Quando de uma etapa 4.2, o dispositivo recebe uma men sagem de anúncio proveniente de um dispositivo distante.

[0081] Quando de uma etapa 4.3, o dispositivo verifica então se o dispositivo distante do qual recebeu o anúncio é conhecido. Vantajosamente. Ele mantém uma mesa das máquinas conhecidas, que lhe basta verificar, portanto, nessa mesa, se uma entrada existe para esse dispositivo distante.

[0082] Se o dispositivo for conhecido, não haverá nada a fazer, circuita-se em espera do recebimento de uma outra mensagem de anúncio.

[0083] Se o dispositivo não for conhecido, ele é acrescentado na mesa, quando de uma etapa 4.4. Cria-se uma entrada na tabela das máquinas conhecidas que se informa com o nome do dispositivo distante, seu endereço IP e o porto sobre o qual pode ser juntado.

[0084] Quando de uma etapa 4.5 se estabelece uma conexão com esse dispositivo distante. Essa conexão pode assumir a forma de socket INET dedicada à comunicação entre máquinas. Vantajosamente, criam-se dois sockets INET , um utilizando o protocolo TCP (Transmission Control Protocol, em inglês) dedicado às trocas de mensagens e um outro utilizando protocolo UDP (User Datagram Protocol, em inglês) dedicado a mensagens de sinalização, como a passagem de anúncio.

[0085] No final dessa fase descoberta intermáquina, os módulos de gestão do barramento de cada linha mestre de cada máquina conectada ao barramento são todos interconectados. No nível de cada máquina, todas as máquinas distantes são conhecidas e referenciadas. Um enlace de comunicação é estabelecido para cada uma dessas máquinas distantes.

[0086] A troca de mensagem entre dois módulos softwares clien tes do barramento utiliza a mesma interface de programação, a API (Application Programmation Interface, em inglês) de acesso ao barra- mento, independentemente do tipo de módulo software.

[0087] A troca de mensagens entre dois módulos de softwares cli entes do barramento que dependem de um mesmo módulo de gestão do barramento é ilustrado pela figura 5. Nessa caso, os dois clientes são tipicamente tarefas no meio de uma mesma linha.

[0088] Quando de uma etapa 5.1, o emissor posta sua mensagem via a API do barramento, especificando o nome do destinatário.

[0089] Quando de uma etapa 5.2, o módulo de gestão do barra- mento percebe que o destinatário faz parte de seu perímetro, por exemplo, comparando a referência do módulo de gestão do barramen- to do destinatário no meio, posta a mensagem na FIFO simples deste.

[0090] Quando de uma etapa 5.3, o destinatário recupera a(s) mensagem(ns) que lhe são destinadas por uma operação de extração da FIFO simples.

[0091] A troca de mensagens entre dois módulos softwares clien tes do barramento que não dependem de um mesmo módulo de gestão do barramento, mas são hospedadas no meio de uma mesma linha é ilustrada pela figura 6.

[0092] Quando de uma etapa 6.1, o emissor posta sua mensagem via a API do barramento, especificando o nome do destinatário.

[0093] Quando da etapa 6.2, o módulo de gestão do barramento percebe que o destinatário não faz parte de seu perímetro, por exemplo, comparando a referência do módulo de gestão do barramento do destinatário e o seu, posta a mensagem na FIFO do módulo de gestão do barramento do destinatário.

[0094] Quando de uma etapa 6.3, o módulo de gestão do barra- mento do destinatário extrai a(s) mensagem(ns) presente(s) em sua FIFO, as postam na FIFO do destinatário dessas mensagens.

[0095] Quando de uma etapa 6.4, o destinatário recupera a(s) mensagem(ns) que lhe são destinadas por uma operação de extração da FIFO.

[0096] Com referência à transmissão de uma mensagem entre um emissor / receptor constituídos por módulos de softwares clientes do barramento que se acham sobre linhas diferentes, a transmissão utiliza módulo de software relé. O barramento dispõe então de meios para inicializar no meio de cada linha um módulo software cliente do barra- mento gerado pelo barramento e que serve de relé do módulo de software distante. Assim, um módulo de software relé do destinatário é criado no meio da linha do emissor, enquanto que um módulo software relé do emissor é criado no meio da linha do destinatário. Esses módulos softwares relés são gerados pelo barramento. Assim, vista do emissor ou do destinatário, a comunicação aparece como sendo sempre interna à linha. As mesmas primitivas podem ser empregadas pelos módulos softwares clientes do barramento. É o barramento que gera a comunicação interlinha, via esses módulos softwares relés. Esses módulos softwares relés permitem também um funcionamento assíncrono das comunicações. Com efeito, o emissor posta sua mensagem junto ao módulo software relé do destinatário e pode continuar seu tratamento. Durante esse tempo, o barramento encaminha a mensagem em direção ao destinatário real, por meio de uma conexão in- terlinha, tipicamente um socket UNIX.

[0097] Com referência a essa comunicação entre linhas, viu-se que, na inicialização do barramento, um enlace de comunicação foi estabelecido entre as linhas escravas e a linha mestre. Ao contrário, não há enlace cria entre as linhas escravas entre si. Por conseguinte, conforme a necessidade, isto é, quando o emissor e o destinatário são hospedados por duas linhas escravas, um enlace é criado, tipicamente um socket UNIX, entre as duas linhas escravas.

[0098] A linha de transmissão entre um emissor e um destinatário hospedados sobre máquinas diferentes é realizada exatamente no mesmo esquema. Ele implica também um módulo relé do emissor no meio da linha do destinatário e um módulo relé do destinatário no meio da linha do emissor. Uma fase de roteamento gerada pelos módulos de gestão do barramento das linhas mestres das duas máquinas permite a criação de uma conexão direta entre as duas linhas. A conexão é no caso tipicamente um socket INET.

[0099] A comunicação é então realizada, tal como ilustrado pela figura 7.

[00100] Quando de uma primeira etapa 7.1, o módulo software cliente do barramento que deseja emitir uma mensagem que se denomina o emissor efetua uma etapa de roteamento com o nome do destinatário junto ao barramento, isto é, junto ao módulo de gestão do barra- mento do qual ele depende.

[00101] Quando de uma etapa 7.2, como o barramento percebe que o destinatário não está hospedado pela mesma linha, ele cria o módulo software relé desse mesmo destinatário no meio da linha do emissor. Em certos modos de realização, esse módulo relé pode ser pré- existente, por exemplo, no meio da linha mestre, caso se criem relés, quando da fase de inicialização, ver a etapa opcional 3.5.

[00102] Quando da etapa 7.3, a mensagem é então transmitida a esse módulo software relé, conforme o mecanismo descrito para uma transmissão de mensagens no meio da linha. Se a comunicação for assíncrona, o emissor poderá então retomar seu tratamento.

[00103] Quando da etapa 7.4, o barramento vai criar, conforme a necessidade, o enlace de conexão direta com a linha que hospeda o destinatário. Vários casos se apresentam aqui. Se a comunicação ocorrer no meio de uma mesma máquina, entre uma linha escrava e uma linha mestre, o enlace de comunicação já existirá. A criação é inútil. Se a comunicação ocorrer no meio de uma mesma máquina, entre duas linhas escravas, o enlace de comunicação deverá ser criado entre as duas linhas escravas, tipicamente sob a forma de um socket UNIX. Se a comunicação ocorrer entre duas máquinas diferentes, o enlace direto deve ser criado entre duas linhas, tipicamente sob a forma de um socket INET. Essa criação é negociada pelas linhas mestres das duas máquinas que trocam os endereços e portos necessários.

[00104] Quando da etapa 7.5, o barramento cria no meio da linha que hospeda o destinatário um módulo software relé do emissor.

[00105] Quando da etapa 7.6, a mensagem é então transmitida entre os dois relés via o enlace de comunicação direta estabelecido entre as duas linhas.

[00106] Uma última etapa 7.7 consiste então em transmitir a mensagem via os mecanismos interlinhas já descritos ao destinatário final.

[00107] Vantajosamente a nomeação dos módulos softwares clientes do barramento intervém segundo um esquema derivado do esquema utilizado para as URL (Uniform Ressources Locator, em inglês). Segundo esse esquema, o nome de um módulo se decompõe da seguinte maneira: "ism://nome_máquina/nome_módulo_software" no qual ism é o nome dado à linha do barramento, de acordo com a invenção. No meio de uma mesma máquina, uma nomeação relativa reduzida a "nome_módulo_software" pode ser utilizado.

[00108] Vantajosamente, as diferentes recopias das mensagens nas FIFOs no meio de uma mesma linha são evitadas. A mensagem sendo copiada uma vez em um espaço memória comum, só uma referência sobre essa mensagem é em seguida trocada. Isto permite limitar as novas cópias efetivas.

[00109] Representou-se na figura 8, um exemplo de configuração de um dispositivo de tratamento de informação 3, em um instante determinado, tendo particularidades em relação aos dispositivos de tratamento de informação representados nas figuras 1 e 2 da presente descrição, particularidades que sobressaíram com a leitura da sequência da presente descrição.

[00110] Conforme se pode constatar, no momento considerado, esse dispositivo de tratamento de informação 3 permite a execução em paralelo de três linhas 3.1, 3.2 e 3.3. Essas três linhas são programadas por um sistema de exploração 3.0 do dispositivo de tratamento de informação 3.

[00111] A linha 3.1 contém ela própria várias linhas 3.11, 3.12 3.13 que são executadas em paralelo sendo programadas pelo sistema de exploração 3.0. Ela contém um módulo de gestão do barramento de tipo linha 3.10.

[00112] A linha 3.11 contém tarefas de sistema, a saber um módulo de comunicação de tipo interlinha 3.118, permitindo a troca de mensagens entre linhas (conforme será explicitado abaixo) assim como um módulo de comunicação de tipo interdispositivo 3.119, permitindo a troca de mensagens entre diferentes dispositivos de tratamento de informação. A linha 3.12 contém duas tarefas de usuário 3.121 e 3.122, assim como um módulo de gestão do barramento de tipo linha 3.120, incluindo programador proprietário (não representado) de todas as tarefas da única linha 3.12, no caso as duas tarefas 3.121 e 3.122. A linha 3.13 contém uma tarefa de usuário 3.131, assim como um módulo de gestão do barramento de tipo linha 3.130, incluindo programador proprietário da tarefa usuário 3.131.

[00113] A linha 3.2 contém uma linha 3.21 e um módulo de gestão do barramento de tipo linha 3.20. A linha 3.21 contém uma tarefa de usuário 3.211 e uma tarefa do sistema, a saber um módulo de comunicação de tipo interlinha 3.218, assim como um módulo de gestão do barramento de tipo linha 3.210, incluindo o programador proprietário de todas as tarefas da única linha 3.21, no caso a tarefa do usuário 3.211 e o módulo de comunicação 3.218.

[00114] A linha 3.3 contém duas linhas 3.31 e 3.32, e um módulo de gestão do barramento de tipo linha 3.30. A linha 3.31 contém uma ta- refa do usuário 3.311 e uma tarefa do sistema, a saber o módulo de comunicação de tipo interlinha 3.318, assim como um módulo de gestão do barramento de tipo linha 3.310, incluindo o programador proprietário de todas as tarefas da linha 3.31, no caso a tarefa 3.311 e o módulo de comunicação 3.318. Quanto à linha 3.32, ela compreende duas tarefas do usuário 3.321 e 3.322, assim como um módulo de gestão do barramento de tipo linha 3.320 incluindo o programador proprietário de todas as tarefas da linha 3.32, no caso as tarefas 3.321 e 3.322.

[00115] Constata-se que a arquitetura de programação é hierárquica e comporta assim, no meio de uma mesma linha, uma ou várias linhas incluindo ela própria uma ou várias tarefas. Além disso, a programação das linhas será considerada como preemptiva e realizada pelo sistema de exploração 3.0 do dispositivo de tratamento de informação. Quanto à programação das tarefas no meio de uma linha, será considerada como preemptiva ou não e realizada por um programador proprietário, isto é, dependente dessa linha.

[00116] Anotar-se-á que, em um outro momento, essa configuração poderá ter de evoluir de fato, por exemplo, uma tarefa, uma linha, até mesmo uma linha que terminou sua execução, ou ainda que uma tarefa se deslocou em um modo dito nômade de uma linha para uma outra linha, da mesma linha ou de uma linha diferente.

[00117] Cada módulo de gestão do barramento de tipo linha compreende uma FIFO protegida, assim como as FIFOs que são respectivamente dedicados às tarefas do usuário da linha correspondente. A função dessas FIFOs é explicitada abaixo. Essas FIFOs não estão representadas na figura 8 para não sobrecarregar essa figura.

[00118] Cada módulo de gestão do barramento de tipo linha 3.10, 3,20 e 3.30 contém, além disso, uma mesa de roteamento 3.101, 3.201, 3.301, na qual são armazenados, para cada tarefa, o respectivo nome e a respectiva referência à FIFO no módulo de gestão do barra- mento de tipo linha correspondente.

[00119] Cada tarefa tem a possibilidade de emitir e de receber mensagens de comando, emitir e receber respostas a mensagens de comando e emitir e receber notificações e emitir e receber respostas sobre notificação.

[00120] Para emitir uma mensagem de comando, uma tarefa chama um método tipificado único para esse tipo de mensagem, aceitando em parâmetros a referência da tarefa referida fornecida quando de seu registro no meio desse barramento referido, o nome do barramento e aquele da tarefa referidos (<no- me_barramento_distante>/<nome_tarefe_distante>), eventualmente se a tarefa desejar uma resposta, uma referência e uma função callback prototipada pelo barramento para esse tipo de resposta, assim como os parâmetros necessários à execução do comando.

[00121] Para receber uma mensagem de comando, uma tarefa posiciona, por meio de um método exposto por esse barramento para esse tipo de recebimento de comando, uma função acionada por ocorrência (ditas em inglês call-back) prototipada por esse barramento, assim como uma referência utilizada para o acionamento dessa função.

[00122] Para emitir uma notificação, uma tarefa apela para um método tipificado único para o tipo de notificação, aceitando em parâmetros a referência da tarefa referida que é fornecida, quando de seu registro no meio desse barramento, eventualmente se a tarefa desejar uma resposta, uma referência e uma função callback prototipada pelo barramento para esse tipo de resposta, assim como os parâmetros necessários à notificação.

[00123] Enfim, para receber uma notificação, uma tarefa posiciona o nome do barramento referido e o nome da tarefa referida <no- me_barramento_distante>/<nome_tarefa_distante>, uma função acio- nada por ocorrência (callback) prototipada por esse barramento e uma referência para o acionamento dessa função.

[00124] Para emitir uma mensagem de resposta a uma mensagem de comando ou a uma notificação, um módulo de gestão de barramen- to apela para um método tipificado único para esse tipo de resposta, aceitando em parâmetros a referência da mensagem fornecida pelo apelo à função callback pré-assinada ao recebimento dessa mensagem e os parâmetros necessários a essa função.

[00125] As diferentes tarefas, as diferentes linhas e linhas representadas na figura 1 pertencem a uma mesma entidade lógica, denominada barramento de software que é nomeado a título de exemplo "bar- ramento_1".

[00126] A invenção utiliza uma arquitetura hierárquica mes- tre/escravo unicamente para a função de roteamento. Assim, no meio de um dispositivo de tratamento de informação, uma linha é inicializa- da em modo mestre e as outras linhas do mesmo dispositivo são ini- cializadas em modo escravo. No exemplo de configuração representada, no meio do dispositivo de tratamento de informação 1, a linha 3.1 é assim inicializada em modo mestre e as linhas 3.2 e 3.3 são inicializa- das em modo escravo.

[00127] Anotar-se-á que vários barramentos de nomes diferentes, incluindo uma linha mestre e linhas escravas podem coexistir em um mesmo dispositivo de tratamento de informação.

[00128] A linha mestre 3.1 possui um módulo de comunicação de tipo interlinha 3.118 da linha mestre 3.1 que está em modo de escuta sobre um socket Unix denominado "/var/run/barramento_1/Master" e os módulos de comunicação de tipo interlinha 3.218 e 3.318 estão em modo conexão em direção ao socket Unix da linha mestre 3.1.

[00129] Anotar-se-á que, em geral, os nomes dos barramentos das linhas mestre e escravas são idênticos em um mesmo dispositivo de tratamento de informação, mas nada impede o contrário.

[00130] Após conexão entre linhas escravas e linha mestre, e identificação e autenticação com lista de acesso, as linhas escravas 3.2 e 3.1 possuem conexões para a linha mestre respectivamente sobre os portos 3.118_12 e 3.118_13. Cada conexão das linhas é reconhecida como uma conexão para o nome de barramento considerado, no caso o barramento "barramento_1".

[00131] Para a linha de roteamento das mensagens entre tarefas, a invenção utiliza uma arquitetura hierárquica centralizada, enquanto que para a troca das mensagens entre tarefas ela utiliza uma arquitetura distribuída. Para ilustrar essas duas características são dados abaixo exemplos de utilização de trocas de mensagens transmitidas entre tarefas.

[00132] Considera-se assim como no meio do dispositivo de tratamento de informação 1 e de uma mesma linha, quer seja mestre ou escrava, uma tarefa deseja enviar uma mensagem para uma outra tarefa fazendo parte da mesma linha que ela. Por exemplo, a tarefa chamada 3.321 deseja enviar uma mensagem determinada à tarefa chamada 3.322 fazendo parte da mesma linha 3.32. O módulo de gestão do barramento de tipo linha 3.320 toma em carga a mensagem em questão e demanda ao módulo de gestão do barramento de tipo linha 3.30 o endereço que deve seguir a mensagem. Provido de sua mesa de roteamento 3.301, um módulo de gestão do barramento de tipo linha 3.30 lhe responde com a referência da FIFO não protegida dedicada à tarefa 3.322 hospedada pelo módulo de gestão do barramento de tipo linha 3.320. Esse módulo de gestão do barramento de tipo linha 3.320 posta então essa mensagem nessa FIFO e aciona uma demanda de programação dessa tarefa do destinatário 3.322. Uma vez essa tarefa programada, a mensagem é extraída da FIFO e é considerada pela tarefa 3.322 por apelo à sua função acionada por ocorrência (callback) com os parâmetros contidos na mensagem.

[00133] Considera-se então uma tarefa que, no meio do dispositivo de tratamento de informação 1, deseja enviar uma mensagem a uma tarefa que faz parte de uma outra linha mas sempre da mesma linha. Por exemplo, a tarefa denominada 3.321 deseja enviar uma mensagem determinada a uma tarefa denominada 3.311 que faz parte de uma outra linha 3.31 mas da mesma linha 3.3. O módulo de gestão do barramento de tipo linha 3.320 se encarrega da mensagem em questão e demanda ao módulo de gestão do barramento de tipo linha 3.30 o endereço a seguir. Esta lhe responde com a referência da FIFO protegida do módulo de gestão do barramento de tipo linha 3.310. Esse módulo de gestão do barramento de tipo linha 3.320 posta então a mensagem nessa FIFO protegida do módulo de gestão do barramento de tipo linha 3.310 e, por um meio colocado à disposição pelo sistema de exploração 3.0, efetua uma demanda de programação do módulo de gestão contendo essa FIFO, a saber o módulo de gestão 3.310. Uma vez o módulo de gestão 3.310 programado, o módulo de gestão do barramento de tipo linha 3.310 extrai a mensagem da FIFO protegida, depois, daí para a frente do caso precedente, efetua uma demanda de roteamento junto ao módulo de gestão do barramento de tipo linha 3.30 e obtém-se deste uma referência de uma FIFO não protegida para o recebimento da mensagem pela tarefa destinatária 3.311. O módulo de gestão do barramento de tipo linha 3.310 posta então a mensagem nessa FIFO e efetua um pedido de programação dessa tarefa destinatária 3.311. Uma vez a tarefa programada, a mensagem é extraída da FIFO e é considerada pela tarefa 3.311 por apelo de sua função acionada por ocorrência (callback) com os parâmetros contidos na mensagem.

[00134] Anotar-se-á que se uma FIFO não estiver vazia no momen to em que uma mensagem é aí postada, é que a mensagem ou as mensagens que ela contém não foi / foram ainda extraída(s). Mas isto significa que o despertar da linha correspondente já foi comandado. Poder-se-á, portanto, só efetuar o despertar da linha em questão, no caso em que a FIFO está vazia.

[00135] Anotar-se-á também que a linha de roteamento é sistemati camente efetuada, a fim de satisfazer o lado nômade das tarefas dos usuários. Enfim, mesmo se a tarefa destinatária tiver migrado antes da extração da mensagem da FIFO protegida, a linha de roteamento permitirá o novo roteamento necessário.

[00136] Considera-se então que, no meio do dispositivo de tratamento de informação 1, uma tarefa em uma linha de uma linha escrava deseje enviar uma mensagem a uma outra tarefa hospedada em uma linha da linha mestre. Por exemplo, a tarefa 3.321 deseja enviar uma mensagem determinada à tarefa denominada 3.121 hospedada na linha 3.12 da linha 3.1. O módulo de gestão do barramento de tipo linha 3.320 toma em carga a mensagem e demanda ao módulo de gestão do barramento de tipo linha 3.30 a rota a seguir para essa mensagem. O módulo de gestão 3.30 lhe responde dessa vez que a tarefa destinatária 3.121 lhe é desconhecida. Ele armazena a mensagem a transmitir e emite uma mensagem de tipo "pesquisa de tarefa distante" (como emanando da tarefa local 3.321), pedindo emprestada a conexão de sinalização 3.318_13. O módulo comunicação 3.118 da linha 3.1 da linha 3.11 recebe, em sua conexão 3.118_33, a mensagem de tipo "pesquisa de tarefa distante" e informa o módulo de gestão do barramento de tipo linha 3.10 que então mantém sua mesa de roteamento 3.101.

[00137] Na mesa de roteamento 3.101 do módulo de gestão 3.10, a tarefa 3.121 destinatário é conhecida como residindo na linha 3.12. De acordo com a invenção, o módulo de gestão do barramento de tipo linha 3.10 cria uma tarefa relé distante R3.321 com as características extraídas da mensagem de pesquisa sobre a mesma linha que o módulo de comunicação que recebeu essa mensagem de pesquisa (no caso, a linha 3.11) e envia ao módulo de gestão 3.30 via a conexão de recebimento da mensagem de pesquisa, a saber a conexão 3.118_33, em resposta a essa mensagem de pesquisa, uma mensagem de tipo "acréscimo tarefa relé" (como emanando da tarefa 3.121) com as características necessárias à criação de uma tarefa relé. O módulo de comunicação 3.318 da linha 3.3 da linha 3.31 recebe sobre sua conexão 3.318_31 a mensagem de tipo "acréscimo de tarefa distante" e informa o módulo de gestão do barramento de tipo linha 3.30. Este cria a tarefa relé R3.121 com as características extraídas da mensagem sobre a mesma linha que o módulo de comunicação que recebeu a mensagem de tipo acréscimo (no caso a linha 3.31) e enriquece sua mesa de roteamento com essa nova tarefa. Segue-se uma pesquisa das mensagens em espera de roteamento correspondendo a esse nome. As mensagens correspondentes são armazenadas na FIFo não protegida dedicada à tarefa destinatária R3.121.

[00138] O módulo de gestão do barramento de tipo linha 3.310 efetua uma demanda de programação dessa tarefa relé R3.121. Uma vez essa tarefa programada, o módulo de gestão do barramento de tipo linha 3.310 serializa a mensagem na conexão 3.318_31 do dispositivo de comunicação 3.318. A conexão 3.118_33 gerada pelo módulo de gestão do barramento de linha 3.110 recebe e desserializa a mensagem. O módulo de gestão 3.110 efetua então todas as operações já descritas para postar a mensagem na FIFO dedicada da tarefa 3.121 e se essa FIFO estiver vazia para efetuar uma demanda de programação. Uma vez a tarefa 3.121 programada, a mensagem é extraída da FIFO e é considerada pela tarefa 3.121 por apelo de sua função acionada por ocorrência (call-back) com os parâmetros contidos na mensagem.

[00139] Conforme será compreendido, a tarefa 3.321 poderá se comunicar com a tarefa 3.121 por intermédio das tarefas relés R3.121 da linha 3.31 e R3.321 da linha 3.11.

[00140] Considera-se ainda que no meio do dispositivo de tratamento de informação 1, uma tarefa de uma linha escrava deseje enviar uma mensagem de dados a uma outra tarefa que é então hospedada em uma linha de uma outra linha escreva. Por exemplo, a tarefa 3.321 deseje enviar uma mensagem determinada à tarefa denominada 3.211 hospedada pela linha 3.2 sobre a linha 3.21. O módulo de gestão do barramento de tipo linha 3.320 recebe a mensagem e demanda ao módulo de gestão do barramento de tipo linha 3.30 o caminho a seguir para a mensagem. Este lhe responde que a tarefa destinatária é desconhecida. Ele armazena a mensagem e emite uma mensagem de tipo "pesquisa de tarefa distante" (como emanando da tarefa 3.321), pedindo emprestado o módulo de comunicação de tipo interlinha 3.318. O módulo de comunicação 3.118 da linha mestre 3.1 e da linha 3.111 recebe a mensagem de tipo "pesquisa de tarefa distante" sobre sua conexão de tipo sinalização 3.118_33 e informa o módulo de gestão do barramento de tipo linha 3.10 que olha na tabela de roteamento 3.101.

[00141] Nesta, a tarefa destinatária 3.211, já que ela não está hospedada pela linha mestre 3.1, não é conhecida. O módulo de gestão do barramento de tipo linha 3.10 difunde essa mensagem de pesquisa em todas as conexões que são estabelecidas levando o nome do bar- ramento considerado, "barramento_1", diferente daquela que viu transitar essa primeira mensagem de pesquisa, isto é, nas conexões que levam o nome "barramento_1" do módulo de comunicação 3;119 e 3.118_32. Em sequência ao recebimento, sobre sua conexão, dessa mensagem de tipo "pesquisa de tarefa distante", cada módulo de comunicação informa o módulo de gestão do barramento de tipo linha do qual ele depende, o qual olha em sua mesa de roteamento da presença ou não da tarefa destinatária pesquisada.

[00142] Só o módulo de comunicação 3.218 da linha 3.2 da linha 3.21 tem em uma sua mesa de roteamento 3.201 a tarefa considerada 3.211 que reside sobre a mesma linha e sobre a mesma linha que ele e aí adverte o módulo de gestão do barramento do tipo linha 3.20, o qual cria sobre a mesma linha 3.21 que o módulo de comunicação 3.218 que recebeu a mensagem de pesquisa, uma tarefa relé R3.321 com as características extraídas da mensagem de pesquisa, enriquece sua mesa de roteamento, efetua uma pesquisa de mensagem em espera de roteamento, conforme já explicado acima e transmite uma mensagem de tipo "acréscimo de tarefa relé distante" (como emanando da tarefa 3.211) com, como parâmetros de conexão, o nome do so-cket Unix denominado "/var/run/barramento_1/escrava_3.2". O módulo de comunicação 3.118 da linha 3.1 da linha 3.11 recebe a mensagem de tipo "acréscimo de tarefa relé distante" sobre sua conexão 3.118_32 e propaga este em direção à conexão 3.118_33 de onde vinha o pedido de pesquisa primeira. O módulo de comunicação 3.318 da linha 3.3 da linha 3.31 recebe, por sua vez, a mensagem de tipo "acréscimo de tarefa relé distante" sobre sua conexão 3.318_31 e informa-lhe o módulo de gestão do barramento de tipo linha 3.30.

[00143] Esta cria então, sobre a mesma linha 3.31 que hospeda o módulo de comunicação 3.318 que recebeu a mensagem de tipo "acréscimo de tarefa relé distante" 3.318, a tarefa relé R3.211 com as características extraídas da mensagem de pesquisa, depois enriquece sua mesa de roteamento 3.301 dessa tarefa relé R3.211. Por outro lado, ele inicializa uma demanda de conexão com as informações contidas nessa mensagem de tipo "acréscimo de tarefa relé distante", depois sobre aceitação da conexão uma fase de identificação e de autenticação com lista de acesso. Segue-se uma pesquisa das mensagens em espera de roteamento correspondente a esse nome. As mensagens correspondentes são armazenadas na FIFO não protegida dedicada à tarefa destinatária R3.211.

[00144] O módulo de gestão do barramento de tipo linha 3.310 efetua uma demanda de programação dessa tarefa relé R3.211. A tarefa relé R3.211 é programada, o módulo de gestão do barramento de tipo linha 3.310 serializa a mensagem na conexão 3.318_32 contida no módulo de comunicação 3.318. A conexão 3.218_33 gerada pelo módulo de gestão do barramento de linha 3.210 recebe e desserializa a mensagem.

[00145] O módulo de gestão 3.210 efetua então todas as operações já descritas para postar a mensagem na FIFO dedicada da tarefa 3.211 e, se essa FIFO estiver vazia, para efetuar uma demanda de programação. Uma vez a tarefa 3.211 programada, a mensagem é extraída da FIFO e considerada pela tarefa 3.211 por apelo de sua função acionada por ocorrência (call-back) com os parâmetros contidos na mensagem.

[00146] Pode-se estender este último módulo de funcionamento na troca de mensagens entre dispositivo de tratamento de informação, a mensagem de tipo acréscimo de tarefa distante chegará então pelo módulo de comunicação interdispositivo 3.119 com as informações de um socket Inet do tipo endereços ip:port. Nesse caso, uma fase de se- rialização /desserialização é necessária.

[00147] Em modo nômade, o funcionamento de um barramento, de acordo com a invenção, é o seguinte.

[00148] Considera-se que no meio do dispositivo de tratamento de informação 1, a tarefa nômade 3.321 é desregistrada do barramento. O módulo de gestão do barramento de tipo linha correspondente 3.320 vai liberar a fonte FIFO, a fonte do programador e a fonte referência fornecida, quando do registro. Ele gera também uma mensagem de eliminação de tarefa distante 3.321 a todas as tarefas locais de todas as linhas da linha e a todas as conexões de tipo sinalização da linha por intermédio do módulo de comunicação 3.318. A conexão 3.118_33 do dispositivo de comunicação 3.118 recebe essa mensagem, ele informa o módulo de gestão do barramento de tipo linha 3.10 que verifica se ele possui tarefas relé distantes correspondentes. Se esse for o caso, ele vai liberá-las. Se mensagens estiverem em espera de quitação, estas serão inseridas na FIFO de espera de linha de pesquisa de tarefa distante, linha que vai, portanto, se relançar. O módulo de gestão do barramento de tipo linha vai também verificar se conexões de tipo data se encontram sem enlace em direção das tarefas relé distantes. Se este for o caso, ele vai liberar essa conexão e propagar a mensagem sobre todas essas conexões de sinalização diferente daquela de onde vem a mensagem, seja 3.118_32 e 3.119. A conexão 3.128_31 do dispositivo de comunicação 3.218 recebe essa mensagem, ele informa o módulo de gestão do barramento de tipo linha que verifica se ele possui tarefas relé distantes correspondentes. Se este for o caso ele vai liberá-las. Se essas mensagens estivessem em espera de quitação, estas seriam reinseridas na FIFO de espera de linha de pesquisa de tarefa distante, linha que vai, portanto, ser relançada. O módulo de gestão do barramento de tipo linha vai também verificar se conexões do tipo data se acham sem enlace em direção às tarefas relé distantes. Se este for o caso ele vai liberar essa conexão.

[00149] Se, além disso, a tarefa 3.321 for inserida na linha 3.21 da linha 3.2, a mesa de roteamento do módulo de gestão do barramento de tipo linha 3.20 é enriquecida por esse nome. Segue-se um procedimento de pesquisa das mensagens em espera correspondendo a esse nome. Além disso, as mensagens de pesquisas correspondentes a esse nome serão honradas.

[00150] Em suma e em relação com a figura 9, para transmitir uma mensagem de uma primeira tarefa 3.321 a uma segunda tarefa, um processo de troca de mensagens, de acordo com a invenção, comporta:

[00151] - as etapas seguintes utilizadas pelo módulo 3.320 de ges tão de barramento da linha 3.32 hospedando essa primeira tarefa 3.321:

[00152] - quando essa segunda tarefa 3.322 ou 3.311 pertence à mesma linha 3.3 que a primeira tarefa 3.321, uma etapa 5.1 de postagem dessa mensagem na FIFO dedicada a essa segunda tarefa 3.322, a fim de que esta possa considerá-la, caso contrário;

[00153] - uma etapa 5.2 de transmissão a esse módulo 3.10 de ges tão de barramento da linha mestre 3.1 de uma mensagem de pesquisa da segunda tarefa;

[00154] - as etapas seguintes utilizadas pelo módulo 3.10 de gestão de barramento da linha mestre 3.1:

[00155] - quando essa segunda tarefa 3.121 é hospedada por uma linha 3.12 dessa linha mestre 3.1;

[00156] - uma etapa 5.3 de criação de uma tarefa relé distante 3.321 no meio de uma linha 3.11 dessa linha mestre 3.1;

[00157] - uma etapa 5.4 de transmissão de uma resposta a esse módulo 3.320 de gestão de barramento da linha 3.32 hospedando a primeira tarefa 3.321;

[00158] - caso contrário

[00159] - uma etapa 5.5 de difusão a cada um desses módulos de gestão de barramento de tipo linha (no caso, o único módulo 3.20 uma mensagem de pesquisa da segunda tarefa;

[00160] - as etapas seguintes utilizadas pelo módulo 3.20 de gestão de barramento de uma linha escrava 3.2 hospedando a segunda tarefa 3.211, com recebimento de uma mensagem de pesquisa da segunda tarefa;

[00161] - uma etapa 5.6 de criação de uma tarefa relé distante R3.321 no meio de uma linha 3.21 dessa linha escrava 3.2;

[00162] - uma etapa 5.7 de transmissão de uma resposta a esse módulo 3.10 de gestão de barramento da linha mestre 3.1;

[00163] - a etapa 5.8 utilizada, além disso, pelo módulo 3.10 de gestão de barramento da linha mestre 3.1 em sequência ao recebimento da resposta transmitida pelo módulo 3.20 de gestão da barra da linha escravo 3.2, de transmissão de uma resposta a esse módulo 3.30 de gestão de barramento da linha 3.32 que hospeda a primeira tarefa 3.321; e

[00164] - as etapas seguintes utilizadas pelo módulo 3.30 de ges tão de barramento da linha 3.32 que hospeda essa primeira tarefa 3.321, quando tiver recebido uma resposta desse módulo 3.10 de gestão de barramento da linha mestre 3.1:

[00165] - uma etapa 5.9 de criação de uma tarefa relé R3.211 cor respondente a essa tarefa relé distante R3.321 no meio de uma linha 3.31 dessa linha 3.3 hospedando essa primeira tarefa 3.321, e

[00166] - uma etapa 5.10 de postagem dessa mensagem na FIFO dedicada a essa tarefa relé R3.211, a qual o transmitirá à tarefa relé distante R3.321, depois à segunda tarefa 3.211.

[00167] Assim, conforme foi ilustrado abaixo, a invenção propõe um sistema de comunicação entre tarefas diferentes pertencentes a diferentes linhas, elas próprias pertencentes a linhas diferentes, essas tarefas sendo agrupadas sob uma mesma entidade ou barramento de software ou pertencente, ao contrário, a barramentos de softwares diferentes.

[00168] De maneira geral, essa comunicação entre tarefas utilizam um modo cliente / servidor de tipo comando / resposta à base de mensagens 1 para 1 ou 1 para n e de tipo notificação / resposta à base de mensagem 1 para n. Ela utiliza um sistema de nomeação das tarefas clientes segundo um formato <nome de barramento> / <nome de tarefa>. Essa comunicação pode ser feita diretamente tarefa para tarefa ou indiretamente por serviço interposto, tal como um sistema de tarefas produtor de comando para serviço, depois de serviço para tarefas de leitora de notificação. Essa comunicação intervém no meio de um mesmo dispositivo de tratamento, mas pode também intervir entre dois dispositivos de tratamento da informação. Além disso, para essa comunicação, a tarefa pode ser hospedada e/ou se deslocar sobre esse ou aquele dispositivo de tratamento de informação ou essa ou aquela linha.

[00169] A comunicação se baseia no nome do barramento e no nome da tarefa, em uma arquitetura hierárquica de programação, em uma arquitetura centralizada para a função roteamento, em uma arquitetura distribuída para a troca de mensagens, sobre fases de descobertas e de registro / desregistro das diferentes tarefas em um oui vários nomes de barramento.

Claims

1. Processo de troca de mensagens entre tarefas clientes de um mesmo barramento que se desenrolam em pelo menos um dis-positivo de tratamento de informação, compreendendo um sistema de exploração, as referidas tarefas clientes de um mesmo barramento se desenrolam em diferentes linhas que são programadas em diferentes processos do referido sistema de exploração, cada processo compre-endendo um módulo de gestão de barramento de processos, e cada linha contendo uma FIFO para cada tarefa que essa linha contém, assim como um módulo de gestão de barramento da linha e um programador proprietário para a programação das referidas tarefas dessa linha caracterizado pelo fato de que compreende: - antes de qualquer troca de mensagens entre tarefas, uma etapa de inicialização durante a qual um dos referidos processos é eleito processo mestre, enquanto os outros processos são considerados processos escravos, os referidos processos compartilham uma informação indicando qual processo foi eleito como processo mestre e em que, para transmitir uma mensagem de uma primeira tarefa para uma segunda tarefa, compreende as seguintes etapas im-plementadas pelo módulo de gestão de barramento da linha que hospeda essa primeira tarefa; - quando essa segunda tarefa pertence à mesma linha que a primeira tarefa, uma etapa (5.1) de postagem dessa mensagem na FIFO dedicada a essa segunda tarefa, a fim de que ela possa considerá-la, caso contrário - uma etapa (5.2) de transmissão para esse módulo de ges-tão de barramento do processo mestre de uma mensagem de pesquisa da segunda tarefa; - as seguintes etapas implementadas pelo módulo de gestão de barramento do processo mestre: - quando essa segunda tarefa é hospedada por uma linha do processo mestre; - uma etapa (5.3) de criação de uma tarefa relé distante em uma linha desse processo mestre, - uma etapa (5.4) de transmissão de uma resposta a esse módulo de gestão de barramento da linha que hospeda a primeira tarefa; - caso contrário, - uma etapa (5.5) de difusão a cada um desses módulos de gestão de barramento do processo escravo de uma mensagem de pesquisa da segunda tarefa; - as etapas seguintes implementadas pelo módulo de gestão de barramento de um processo escravo que hospeda a segunda tarefa, com recebimento de uma mensagem de pesquisa da segunda tarefa; - uma etapa (5.6) de criação de uma tarefa relé distante em uma linha desse processo escravo, - uma etapa (5.7) de transmissão de uma resposta a esse módulo de gestão de barramento do processo mestre, - uma etapa (5.8), também implementada pelo módulo de gestão de barramento do processo mestre, em sequência ao recebimento da resposta transmitida pelo módulo de gestão de barramento processo escravo, de transmissão de uma resposta a esse módulo de gestão de barramento da linha que hospeda a primeira tarefa; e - as etapas seguintes implementadas pelo módulo de gestão de barramento da linha que hospeda essa primeira tarefa, quando tiver recebido uma resposta desse módulo de gestão de barramento do processo mestre: - uma etapa (5.9) de criação de uma tarefa relé correspondente a essa tarefa relé distante em uma linha desse processo que hospeda essa primeira tarefa; e - uma etapa (5.10) de postagem dessa mensagem na FIFO dedicada a essa tarefa relé de modo que ela possa ser levada em consideração.

2. Processo de troca de mensagens de acordo com a reivin-dicação 1, caracterizado pelo fato de que a dita etapa de inicialização ainda compreende as seguintes etapas: - uma etapa (3.1) na qual os módulos de gestão do barra- mento dos processos escravos estabelecem um enlace de conexão com o módulo de gestão do barramento do processo mestre; - uma etapa (3.2) onde cada tarefa cliente do barramento se registra junto ao módulo de gestão do barramento do processo do qual ele depende; - uma etapa (3.3) de criação de uma FIFO associada a cada tarefa cliente do barramento e a cada módulo de gestão do barra- mento de linha; - uma etapa (3.4) na qual o módulo de gestão do barramen- to de um processo escravo que recebe registros de clientes de módulos de software do barramento exporta esses registros para o módulo de gestão do barramento do processo mestre.

3. Processo de acordo com a reivindicação 2, caracterizado pelo fato de que a referida etapa de inicialização ainda compreende uma etapa (3.5) de criação no processo mestre de tantas tarefas relé quanto tarefas clientes do barramento nos processos escravos.

4. Processo, de acordo com a reivindicação 2 ou 3, caracterizado pelo fato de que o registro das tarefas clientes do barramento com módulo de gestão do barramento compreende informações conhecidas como modo de visibilidade, podendo o modo de visibilidade levar um primeiro valor chamado modo de visibilidade privada ou um segundo valor chamado modo de visibilidade pública, apenas as tarefas registradas com um modo de visibilidade pública são exportadas para o processo mestre.

5. Processo, de acordo com qualquer uma das reivindicações 2 a 4, caracterizado pelo fato de ainda comportar uma etapa de descoberta entre uma pluralidade de dispositivos de tratamento de informação que participam do barramento compreendendo: - uma etapa (4.1) de anúncio na qual cada dispositivo de tratamento de informação que participa no barramento emite um anúncio sobre a rede de comunicação, conectando esses dispositivos de tratamento de informação; - uma etapa (4.2) de recebimento de uma mensagem de anúncio proveniente de um dispositivo de tratamento de informação distante; - uma etapa (4.4) de acréscimo de dispositivo de tratamento de informação originando a mensagem de anúncio recebida em uma tabela, se ele já não for conhecido; - uma etapa (4.5) de estabelecimento de uma conexão com esse dispositivo de tratamento de informação distante.

6. Processo, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que cada módulo de gestão do barramento estabelece que uma tarefa pertence a uma linha de um processo por meio de uma tabela de roteamento listando as tarefas e linhas do referido processo das quais dependem.

7. Processo, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que o referido processo mestre compreendendo um módulo de gerenciamento do barramento hospedado por uma linha do referido processo mestre, o referido processo compreende uma etapa de transmissão de uma mensagem entre uma tarefa relé do referido dispositivo de tratamento de informação e uma tarefa relé distante hospedada por outro dispositivo de tratamento de informação usando o referido módulo de gestão do barramento.