Version imprimable
Bonjour,
Dans un prog multithreads sous Windows avec la VCL, pour attendre la fin de tout les threads de mon spoiler, j’utilise : WaitForMultipleObjects.
Je cherche à porter ce prog sous FMX, de ce fait, je me trouve coincé par cette API spécifique à Windows, à votre avis, existe-t’il un équivalent multiplateforme ou une autre approche pour y arriver ?
Merci d’avance de vos suggestions.
Tu peux utiliser un TEvent et un AtomicIncrement\Decrement
Cherche dans le code WaitForMultipleObjects, si cela se trouve tu tomberas dessus dans une encapsulation FMX, il ne semble qu'il n'y a rien de natif ailleurs qu'un polling
Tu peux aussi repenser totalement ta logique avec tu TTask et TParallel
Merci pour ton retour, c’est vrai qu’avec TTask, on a WaitForAll et WaitForAny :king:
Et si l'on regarde le code du WaitForAll, sans suprise si l'on part du TCountdownEvent utilisant du TInterlocked mixé à un TLightweightEvent (encapsulant de TMonitor) ... donc tout ça c'est du AtomicCmpExchange qui reste la clé de base pour gérer les verrous d'attente de thread.
Il faut aussi regarder les implémentations de TMultiWaitEvent, sa fonction Create n'est pas un constructor mais une factory sur l'une des implémentations RTL
Dès que tu intègres les unités contenant TTask ou TCriticalSection au projet, l'implémentation change et je ne vois pas un développeur s'intéressant au multi-thread ne pas inclure System.SyncObjs (je me demande même pourquoi il en existe une autre variante)
Les développeurs Delphi ont beaucoup travaillé sur ce genre de classe, c'est tout un art, ceux qui ont connu le TMultiReadExclusiveWriteSynchronizer en Delphi 7, il était loin d'être au point lors des promotions de verrou de lecture vers verrou d'écriture, il a bien fallu dix ans avec XE2 pour je lui offre une nouvelle chance (a priori plus de DeadLock mais j'évite aussi de créer cette situation en utilisant systématiquement un rééchantillonage plutôt qu'une promotion directe)
Avec le mot « rééchantillonage », là, j’avoue que tu m’as perdu !
Dans un contexte mutli-read, tu vas lire la valeur, et dans quelques RARES fois, tu voudras la modifier.
L'idée est de faire
Code:
2
3
4
5
6
7
8
9
10
Tu penses qu'entre les deux verrous, il y a une faible chance que la modification soit produite par un autre thread, donc tu vérifies que ce n'est pas le cas.
C'est bien moins dangereux que de faire BeginRead BeginWrite EndWrite EndRead qui d'ailleurs à mon avis doit être limite absurde mais l'imbrication d'un code peut amener à cela sans que cela soit visible dans le code mais uniquement à l'exécution par des appels de fonctions successifs :aie:
Tu peux prendre le risque même de lire dans certains cas, je pense au Singleton que tu veux rendre Thread Safe : voir class function TSLTSingletonThreadSafe<T>.GetThreadSafeInstance(): T;
Je sais qu'il n'y aura qu'une seule et unique première écriture, donc je peux me passer totalement de verrou de lecture, si c'est assigné, c'est fini, sinon, verrou, vérification que c'est toujours non assigné (oui probabilité infime mais existante) et allocation si nécessaire.
:applo:, parfaitement expliqué !