Limbajul Java nu oferă implicit tehnici pentru apeluri asincrone de metode, dar ne sunt oferite tehnologii cum ar fi JMS (Java Message Service) sau Web Services. De sigur ambele sunt soluţii tehnologice foarte bune, dar este oare necesar utilizarea unor intregi sisteme pentru un “banal” apel asincron de metodă. Răspunsul nu este unul simplu, căci depinde foarte mult ce realizează metoda apelată.
În ceea ce urmează aş dori să prezint o soluţie care ar putea să fie o alternativă în cazul în care se doreşte evitarea utilizării unor arhitecturi prea “grandioase”. Structura …

Practica bate teoria, aşa îmi spun mulţi după prima parte “Concurenţă, multithreading şi asincronism” . Aşa că să continuăm, dar puţin altfel…
Framework-ul .Net oferă un mecanism implicit ce permite de apelat asincron orice metodă. Iar activităţile implicate ar trebui:

să definească delegatul cu signatura metodei;
să utilizeze metodele BeginInvoke (apel asincron) şi EndInvoke(apel sincron realizat la finisarea execuţiei) definite automat de CLR;
se urmărească execuţia prin obiectul de tip IAsyncResult, etc.

Pentru exemplificarea  celor menţionate mai sus eu prezint studenţilor mei o aplicaţie banală cu o fereastră pe care sunt plasate două componente ListBox, cărora se adăugă “simultan” elemente.

De stăpânit nedeterminismul este imposibil. De realizat concurenţa nu este uşor.
Susţin acest lucru ori de cîte ori am ocazia să vorbesc despre concurenţă. Mai mult decît atît, uneori chiar recomand studenţilor mei să evite utilizarea multiplelor fire de execuţie. Iar în sistemele elaborate de ei doar o reprezentare mai firească a activităţilor concurente în detrimentul eficienţei sau o concurenţă cu „suport” hardware poate justifica utilizarea lor.
Modelul actual de programare multithreading este perceput de unii ca fiind o adaptare a modelului secvenţial sistemelor concurente. Iar realizarea acestui model este de …