DEV Community: Rafael Rodrigues de Oliveira

Thread #1

Rafael Rodrigues de Oliveira — Wed, 04 Oct 2023 11:14:27 +0000

Vamos explorar o conceito de Threads, mas antes de mergulharmos nesse tópico, é essencial discutirmos sobre Processos, pois eles representam o ponto de partida para entender Threads.

Definição de um Processo

No Sistema Operacional, um Processo é uma abstração de um programa em execução¹. Essa definição não ajuda compreender melhor o que é um Processo, então, vamos para uma compreensão mais detalhada, embora não nos aprofundemos muito, pois nosso foco é discutir Threads.

O Sistema Operacional pode estar executando diversos processos, por exemplo, pode estar realizando atualizações de software, utilizando um navegador para acessar a internet e executando ferramentas para edição de imagens, entre outras tarefas. Embora possa parecer que todos esses processos estão sendo executados ao mesmo tempo, essa percepção é ilusória. Na realidade, a CPU troca (figura 1.0) entre os processos em questão de milissegundos, permitindo a execução de vários processos em um intervalo de tempo muito curto. Isso cria a ilusão de paralelismo, mas na verdade se trata de um pseudoparalelismo². A verdadeira ocorrência de paralelismo nos processos ocorre quando se dispõe de multiprocessadores, isto é, sistemas com duas ou mais CPUs.

Esse mecanismo de troca de processos é possível graças à multiprogramação, na qual o Sistema Operacional divide a memória principal em partições e permite a alocação de diversos processos, possibilitando a alternância entre a execução deles. Conforme mostrado na figura 1.1, onde a memória principal (Memória RAM) esta particionada em vários processos e cada processo é executado uma vez.

figura 1.1

Quando um processo é iniciado, ele pode requerer diversos recursos, tais como espaço de memória, instruções a serem executadas, arquivos abertos, dados de entrada, conexões de rede, entre outros elementos essenciais. Todos esses componentes são encapsulados dentro do próprio processo.

A utilização desses recursos, muitas vezes de alto custo computacional, é um dos motivos para a adoção de threads, embora detalhes a respeito desse tópico sejam deixados para uma discussão posterior. Vale ressaltar que o Sistema Operacional desempenha um papel crucial no gerenciamento desses recursos, supervisionando a alocação de memória, o acesso a dispositivos de armazenamento e a execução dos diversos processos em andamento. A cada novo processo iniciado, é atribuído um PID (Identificador de Processo) único, e tais informações são registradas de maneira estruturada em uma tabela de processos.

Um ponto de relevância que merece destaque é que, mesmo que um programa seja executado em múltiplas instâncias, os processos resultantes podem ser criados de forma distinta, cada qual sendo associado a um PID único. Além disso, os recursos alocados a um processo não são compartilhados com outros processos, mesmo que pertençam ao mesmo tipo ou categoria.

Escalonador

O responsável por gerenciar essa troca de processos na CPU é o escalonador, que determina quais processos devem ser executados e quais devem ser suspensos. Essa troca ocorre de forma tão eficiente que se torna praticamente imperceptível, criando a sensação de execução simultânea.

Em resumo, o escalonador é responsável por decidir qual processo será executado, quando isso acontecerá e por quanto tempo ele permanecerá ativo.

Os processadores com múltiplos núcleos (ou cores) têm a capacidade de executar diversos processos simultaneamente, mas o processo de escalonamento continua sendo fundamental para determinar quais processos serão executados em cada núcleo.

É importante mencionar que existem vários algoritmos de escalonamento disponíveis, embora não entraremos em detalhes sobre eles neste contexto.

Estados de um Processo

Os processos possuem estados que se modificam em resposta ao mecanismo de troca de execução entre eles. Esses estados podem ser classificados como "Em Execução," "Pronto," e "Bloqueado." Tais transições de estado são comumente denominadas "Mudanças de Contexto" ou "Trocas de Contexto". Portanto, quando ocorre a alternância de processos na CPU, é natural que haja uma correspondente alteração no estado do processo.

¹Definição extraída do livro 'Sistemas Operacionais Modernos', de autoria de Tanenbaum, A. S. e Bos, H., na sua 4ª edição, publicada pela [Nome da Editora].

²Termo utilizado no livro 'Sistemas Operacionais Modernos', de autoria de Tanenbaum, A. S. e Bos, H., na sua 4ª edição, publicada pela [Nome da Editora].

DSL (Domain-Specific Languages) - Mergulhando

Rafael Rodrigues de Oliveira — Wed, 14 Jul 2021 18:00:52 +0000

Aprofundando na série de artigos dedicados às Linguagens de Domínio Específico (DSLs).

No nosso artigo inaugural, intitulado "DSL - O Início", fornecemos uma explicação elementar sobre as distinções entre DSLs Internas e DSLs Externas. No entanto, dado o escopo restrito que abordamos apenas as DSLs Internas, é necessário um aprofundamento maior nesse conceito.

DSLs Internas

As DSLs Internas são limitadas pelas restrições impostas pela linguagem hospedeira, que pode ser uma linguagem de programação como Java, C#, Ruby, entre outras.

Quais são essas restrições?

Toda linguagem possui suas particularidades, as quais servem para restringir o que é considerado válido ou inválido na linguagem. Como uma DSL Interna depende de uma linguagem hospedeira, as expressões utilizadas devem ser válidas naquela linguagem específica.

Neste artigo, utilizarei Java como linguagem hospedeira nos exemplos, onde todas as expressões empregadas nas DSLs devem ser compatíveis com a sintaxe e semântica do Java.

Antes de apresentar exemplos de construção de uma DSL, é importante discutir sobre o conceito de Interface Fluente.

Interface Fluente

Possivelmente, em algum momento da sua carreira como desenvolvedor, você já se deparou com o termo "Interface Fluente" e pode tê-lo associado ao encadeamento de métodos. Essa associação não está incorreta, uma vez que a técnica de encadeamento de métodos é utilizada na construção de uma Interface Fluente.

No entanto, é crucial compreender que a Interface Fluente não se limita apenas ao encadeamento de métodos, mas sim à fluidez do fluxo resultante desse encadeamento. Ao realizar chamadas encadeadas, é essencial ter a sensação de um fluxo contínuo e harmonioso.

É importante destacar que o encadeamento de métodos não é a única abordagem para criar esse fluxo. Existem outras técnicas que podem ser empregadas.

Para consolidar o entendimento, a Interface Fluente diz respeito à fluidez do fluxo, enquanto o encadeamento de métodos é apenas uma das técnicas utilizadas para alcançar esse fluxo.

É possível encadear métodos sem obter a fluência desejada, nesse caso, não se trata de uma Interface Fluente, mas apenas da utilização da técnica do encadeamento de métodos.

E qual a diferença das DSLs Internas para Interface Fluente?

Portanto, essa distinção depende do contexto.

O que quero dizer com isso? Quando nos encontramos dentro do âmbito do domínio e criamos expressões baseadas nesse contexto, considero isso como uma DSL Interna. No entanto, quando desenvolvemos expressões que não estão diretamente relacionadas ao domínio, mas são empregadas para a construção de uma API com maior fluência, em vez de utilizar uma API de Comando-Consulta (termo cunhado por Martin Fowler), estamos, então, utilizando uma Interface Fluente.

Essa é a minha maneira de pensar e diferenciar esses dois conceitos. É possível que você encontre interpretações distintas, pois esse é um tema que pode gerar amplas discussões e diferentes pontos de vista.

API Comando-Consulta

De maneira geral, uma API Comando-Consulta consiste em métodos de um objeto que podem retornar um valor sem modificar o estado do objeto (consultas) e métodos que modificam o estado do objeto sem retornar um valor (comandos). As consultas são responsáveis por obter informações e podem ser chamadas várias vezes sem afetar o estado do objeto, enquanto os comandos requerem cautela ao serem invocados devido aos efeitos colaterais que podem gerar.

Essa abordagem permite separar os métodos que não possuem efeitos colaterais (consultas) daqueles que os possuem (comandos). Os métodos getters e setters são exemplos desse tipo de separação.

Todas essas formas de expressão de uma DSL, como encadeamento de métodos, função aninhada e sequência de funções, são conhecidas como construtores de expressões. Esses construtores de expressões são objetos cujo objetivo é construir objetos comuns utilizando uma Interface Fluente.

No próximo artigo, abordaremos com mais detalhes esse conceito.

Formas de Construir DSL Interna

Sequência de Funções

  email();
    de("remetente@email.com");
    para("destinatario@email.com");
    assunto("E-mail Sequência de Funções");
    mensagem("E-mail para Teste");
  enviar();

Encadeamento de Métodos

  email()
    .de("remetente@email.com")
    .para("destinatario@email.com")
    .assunto("E-mail Sequência de Funções")
    .mensagem("E-mail para Teste")
  enviar();

Funções Aninhadas

email(
       de("remetente@email.com.br"), 
       para("destinatario1@email.com.br", "destinatario2@email.com.br"),
       assunto("E-mail Teste"),
       mensagem("Esse E-mail serve para teste do Modelo Semântico")
      );

É importante ressaltar que é possível combinar essas técnicas para a construção de uma DSL.

Agradeço sinceramente pela leitura e espero que este artigo tenha sido do seu agrado.

Referência

DSL - Linguagens Específicas de Domínio - Martin Fowler
DSL - Quebre a barreira entre desenvolvimento e negócios - Leonardo Otto

DSL (Domain-Specific Languages) - O início

Rafael Rodrigues de Oliveira — Thu, 04 Mar 2021 10:28:13 +0000

Recentemente, tenho mergulhado no mundo das DSLs, um tema que sempre me instigou e motivou a buscar um conhecimento mais aprofundado. Quero compartilhar esse conhecimento com vocês, para ajudar a disseminar essa abordagem.

Este artigo é o primeiro de uma série, que irá fornecer uma introdução ao assunto e abordar diversos conceitos relacionados a ele. Os próximos artigos irão se aprofundar nos tópicos apresentados.

Para aqueles que desejam se aprofundar ainda mais, gostaria de indicar dois livros que servem como base para a série que irei escrever.

É importante ressaltar que todos os exemplos de código apresentados serão em Java, mas os conceitos podem ser aplicados em qualquer linguagem de programação.

Então, vamos juntos explorar o fascinante mundo das DSLs!

A Linguagem Específica de Domínio

O que seria uma Linguagem Específica de Domínio?

Basicamente, é uma linguagem de programação criada para um domínio específico, com expressividade limitada.

Mas o que isso significa na prática? Bem, uma DSL é projetada para facilitar a compreensão por humanos, diferentemente de linguagens de propósito geral que possuem diversos recursos, como controle de fluxo e estrutura de dados. Na DSL, a ideia é que ela possua apenas os recursos necessários para o domínio em questão.

É importante destacar que você não irá construir um software inteiro em uma DSL, mas sim utilizá-la em pontos específicos do sistema. O foco é sempre no domínio em questão.

O benefício de construir uma DSL é a criação de uma linguagem de fácil compreensão tanto para especialistas do domínio quanto para desenvolvedores. É uma forma de se ter um vocabulário compartilhado e padronizado entre todas as pessoas envolvidas no projeto.

Portanto, se você precisa trabalhar em um domínio específico e quer tornar a comunicação mais eficiente, a criação de uma DSL pode ser uma ótima solução.

O Modelo

Se você está se aprofundando no mundo de DSLs, certamente já deve ter ouvido falar do Modelo Semântico. Mas, afinal, o que é isso?

Em resumo, o Modelo Semântico é o motor que fornece o comportamento da DSL. Ele define a semântica, ou seja, o que será executado quando o código for rodado.

E qual a relação da DSL com o Modelo Semântico? A resposta é simples: a DSL fornece maneiras de preencher esse modelo.

No entanto, é importante não confundir o Modelo Semântico com o Modelo de Domínio, este último sendo geralmente mais complexo. O Modelo Semântico é uma parte fundamental da construção de uma DSL e pode ser tão simples quanto uma estrutura de dados.

Embora seja possível criar uma DSL sem um Modelo Semântico, é recomendável utilizá-lo em quase todos os casos. Ele é uma das peças-chave para garantir que a sua DSL seja compreendida tanto pelos especialistas do domínio quanto pelos desenvolvedores.

Por fim, é importante entender que, para construir uma DSL, você precisará tanto de uma gramática (que define a ordem das palavras) quanto de uma semântica (que define o que será executado com essa ordem). Juntos, esses elementos formam uma linguagem específica para o seu domínio.

Legal! Queremos código

Que tal explorarmos um exemplo prático de DSL Interna?

Modelo Semântico

public class Email {
  private Remetente remetente;
  private List<Destinatario> destinatarios;
  private Assunto assunto;

public Email(Remetente remetente, 
             List<Destinatario> destinatarios, Assunto assunto) 
{
  this.remetente = remetente;
  this.destinatarios = destinatarios;
  this.assunto = assunto;
}

public boolean enviar(Mensagem mensagem) {
   // Lógica de envido de email...
}

}

public class Destinatario {

private String email;

public Destinatario(String email) {
  this.email = email;
}

public String getEmail() {
  return email;
}

}

public class Remetente {

private String email;

public Remetente(String email) {
  this.email = email;
}

public String getEmail() {
  return email;
}   
}

public class Mensagem {

private String corpo;

public Mensagem(String corpo){
  this.corpo = corpo;
}

public String getCorpo() {
  return corpo;
}
}

public class Assunto {

private String titulo;

public Assunto(String titulo) {
  this.titulo = titulo;
}

public String getTitulo() {
  return titulo;
}
}

DSL Interna

public class EmailDSL {

private EmailDSL() {}

public static void email(String de, String[] para, String assunto, String corpo) {
  List<Destinatario> destinatarios = Arrays.asList(para)
                                   .stream()
                                   .map(email-> new Destinatario(email))
  .collect(Collectors.toList());

  new Email(new Remetente(de), destinatarios, new Assunto(assunto)).enviar(new Mensagem(corpo));  
}

public static String de(String de) {
  return de;
}

public static String[] para(String... para) {
  return para;
}

public static String assunto(String assunto) {
  return assunto;
}

public static String mensagem(String corpo) {
  return corpo;
}
}

@Test
public void dslFuncaoAninhada() {
 email(
       de("remetente@email.com.br"), 
       para("destinatario1@email.com.br", "destinatario2@email.com.br"),
       assunto("E-mail Teste"),
       mensagem("Esse E-mail serve para teste do Modelo Semântico")
      );
}

Neste artigo, apresentamos um exemplo simples de como uma DSL Interna pode ser construída usando funções aninhadas. No entanto, é importante ressaltar que existem outras formas de criar uma DSL, cada uma com suas próprias vantagens e desvantagens.

Ao longo desta série de artigos, iremos explorar algumas dessas outras formas de construir DSLs, de modo a ajudar você a escolher a melhor abordagem para o seu projeto.

DSLs Internas e DSLs Externas

As DSLs podem ser divididas em duas categorias principais: internas e externas.

As DSLs internas são construídas dentro de uma linguagem hospedeira, como no exemplo que apresentamos anteriormente em que utilizamos o Java como linguagem hospedeira. Já as DSLs externas possuem uma linguagem própria e independente da linguagem hospedeira. Essas DSLs externas são geralmente escritas em arquivos separados dos arquivos de código da linguagem de programação principal.

Embora não entraremos em detalhes mais aprofundados sobre as diferenças entre esses dois tipos de DSLs, é importante que você saiba que essas duas categorias existem e que cada uma delas possui vantagens e desvantagens dependendo do seu caso de uso.

Só vou focar nas DSLs Internas.

Nem tudo são flores

A utilização de uma DSL pode trazer benefícios significativos para a expressão de intenções em um determinado domínio, mas também é importante avaliar os custos associados à manutenção e treinamento de novos membros da equipe. É preciso ponderar a complexidade do domínio e o quanto uma DSL pode ajudar a melhorar a expressividade da linguagem.

Ao avaliar a construção de uma DSL, é fundamental pensar nos ganhos que ela pode proporcionar e também nas camadas adicionais que serão incluídas no sistema. Em alguns casos, pode ser mais vantajoso utilizar uma linguagem de propósito geral em vez de criar uma DSL.

Ao finalizar, esperamos que as informações apresentadas possam ajudar na compreensão sobre DSLs e auxiliar no processo de decisão sobre sua utilização em projetos de desenvolvimento de software.

Referência

DSL - Linguagens Específicas de Domínio - Martin Fowler
DSL - Quebre a barreira entre desenvolvimento e negócios - Leonardo Otto