Programação multithread em DELPHI (1)
Sabemos que win95 ou winNT são sistemas operacionais "multithreaded". No DELPHI 2.0, podemos aproveitar ao máximo esse recurso e escrever aplicativos "multithreaded".
Para aqueles que escreveram programas no DOS ou em janelas de 16 bits no passado, "multi-threading" ainda não é familiar, mas assim como fizemos a transição de tarefa única no DOS para multitarefa no Windows 3.1, agora devemos fazer a transição novamente Afinal, para o campo do “multi-threading”, a era da informática está em constante desenvolvimento. No entanto, felizmente, a programação multithread no DELPHI2.0 não exige que aprendamos as enormes funções do WIN32API. Podemos usar a classe multithread padrão TThread no DELPHI para concluir nosso trabalho.
TThread é uma classe abstrata, ou seja, não há necessidade de declarar variáveis baseadas em TThread (e variáveis declaradas com base em TThread são completamente inúteis). O que temos que fazer é usar TThread como classe base e gerá-la em). a forma de herança. Na verdade, é muito fácil escrever aplicativos multithread baseados em TThread.
A seguir está uma classe multithread básica gerada pela herança de TThread.
QuerThrd． Passo
unitQuerThrd;
interface
usa
Classes,DBTables;
tipo
TQueryThreadΚclass(TThread)
Privado
fQuery:tQuery;
protegido
procedimentoExecutar;substituir;
público
construtorCreate(Suspenso: Boolean; Consulta: TQuery);
fim;
implementação
construtor
TQueryThread． Criar(Suspenso: Booleano; Consulta: TQuery);
começar
herdadoCriar(Suspenso);
fQuery: ΚConsulta;
FreeOnTerminate:ΚTrue;
fim;
procedimentoTQueryThread． Executar;
começar
fQuery． Abrir;
fim;
fim.
No exemplo simples acima, construímos uma subclasse TQuery-Thread de TThread para executar consultas ao banco de dados em segundo plano. Na função Create desta classe são passados dois parâmetros Suspended e Query, onde Suspended é utilizado para controlar a execução da thread. Se Suspend for verdadeiro, a thread da classe TQueryThread será suspensa imediatamente após ser estabelecida até o Resume. O método é executado. O thread continuará a ser executado. O parâmetro Query é usado para aceitar um controle de consulta existente (o controle de consulta real no formulário) para fazê-lo ser executado em uma situação multithread. Executar é o processo mais importante. É a parte de execução da classe TQueryThread. Todas as instruções que precisam ser executadas nesta classe multithread devem ser escritas neste processo.
Na verdade, ao construir sua própria classe multithread, você não precisa inserir todos esses códigos. Selecione a nova opção no menu Arquivo do DELPHI e selecione o projeto "TThreadObject" e o DELPHI construirá o módulo básico do programa para você. Então podemos fazer as modificações correspondentes conforme necessário.
Execução do processo:
Suponha que criamos um formulário FORM1, que contém o controle de consulta Query1 que iremos utilizar. Em seguida, adicionamos a unidade QuerThrd escrita acima à parte USES da unidade.
procedimentoTForm1． Button1Click(Remetente: TObject);
começar
{Crie um processo em execução}
TQueryThread． Criar(Falso,Consulta1);
fim;
Se este processo for executado, o controle de consulta Query1 no formulário executará automaticamente a consulta em um ambiente multithread. Observe que existe apenas Create, mas não Free na classe TQueryThread. Depois de criar uma classe dinamicamente e esquecer de excluí-la, esse é um dos erros que cometemos com frequência, pois especificamos FreeOnTerminate (excluir após a execução) como verdadeiro. aqui, quando a instrução em Execute for executada Após a conclusão, o controle de memória ocupado pela classe TQueryThread será liberado automaticamente.
No entanto, há outra questão que merece nossa atenção. Como vários threads podem ser executados ao mesmo tempo, também devemos resolver o problema de sincronização. Se não houver correlação entre vários programas multithread, então não haverá correlação entre eles. qualquer conflito. Mas, na verdade, vários aplicativos de banco de dados multithread podem estar em execução ao mesmo tempo. Como os mesmos recursos de banco de dados precisam ser compartilhados, também precisamos adicionar um controle Tsession à Consulta1.
Na verdade, embora possamos não ter usado pessoalmente o controle de sessão, o DELPHI criará automaticamente um controle de sessão temporário durante todos os acessos ao banco de dados e o excluirá dinamicamente após o uso. Na programação normal do banco de dados, não precisamos fazer isso sozinhos, mas no caso de execução multithread do banco de dados, para não entrar em conflito entre si, devemos customizar nosso próprio controle de sessão para cada acesso ao banco de dados. Este passo é muito simples. Basta adicionar um controle de Sessão ao formulário, depois escrever um nome arbitrário em sua propriedade "Sessionname" e depois escrever o mesmo nome em "Sessionname" da Consulta1. Desta forma, nosso programa de banco de dados está seguro.
Outro tipo de problema de sincronização que precisa ser resolvido são os programas que operam em recursos VCL. Existem muitos desses programas, mas felizmente a solução também é muito simples.
Podemos ver um programa como este:
unidadeBncThrd;
interface
usa
WinProcs, Classes, Gráficos, ExtCtrls;
tipo
TBounceThreadΚclass(TThread)
privado
FormaF: FormaT;
FXSpeed: Inteiro;
FYSpeed: Inteiro;
procedimentoMoveShape;
protegido
procedimentoExecutar;substituir;
público
construtorCreate(Suspenso: Booleano; Forma: TShape; XSpeed, YSpeed: Inteiro);
propriedadeShape: TShapereadFShape;
fim;
implementação
procedimentoTBouad. Mover Forma;
var
MaxHeight, MaxWidth: Inteiro;
começar
comFShapedo
começar
Esquerda: ΚEsquerda+FXSpeed;
Superior: ΚTop+FYSpeed;
se（EsquerdaΙ0）ou
(Esquerda＋LarguraΛPai．Largura)então
FXSpeed: ΚFXSpeed＊-1;
if（TopΙ0）ou
(Topo＋AlturaΛParent.Altura)então
FYSpeed: ΚFYSpeed＊-1;
Blog do autor: http://blog.csdn.net/zou5655/