Metodi (o altro) differiti

[DragoRosso]

Ciao,

vorrei porvi una domanda tecnica, a cui non ho mai trovato risposta.
C'è un modo per capire se un metodo (tipicamente una procedura, ma non solo) lavora in modo differito ?

Per differito intendo che eseguo il metodo e questo "ritorna" subito. Però gli effetti della chiamata si faranno vedere più avanti.

Faccio un esempio che sicuramente tutti conosceranno (a parte i Linuxiani puri forse  ):

1) sendmessage (Api di Windows);
2) postmessage (sempre Api di Windows);

Il primo è un metodo che ritorna solo dopo che viene eseguita tutta la sequenza di operazioni (cioè doposito del messaggio nella coda dei messaggi appopriata).

Il secondo invece è un metodo che ritorna immediatamente, e il messaggio verrà depositato secondo le tempistiche del sistema operativo).

Un altro abbastanza comune è il .Click, con cui si simula il "click" su un oggetto a schermo. Anche questo ritorna immediatamente, l'esecuzione dell'azione è differita sempre secondo le tempistiche del sistema operativo).

Non rispondetemi: "basta guardare il manuale, le istruzioni, etc ....." che non è vero. Nella maggior parte dei casi bisogna testare la singola chiamata per verificare il tutto.

E guardate che la cosa non è ininfluente come possa sembrare: ad esempio ci potrebbe essere un problema per cui il metodo differito non viene eseguito e magari non viene segnalato, etc ....

Saluti

[Stilgar]

Ciao.


Posta in questi termini mi fai pensare alle chiamate rientranti (o differite) vs chiamate bloccanti.
In genere la prima tipologia l'ho sempre associata allo start di un thread (o installazione di una isp se parliamo di micro controllori/vecchio msdos - gestore di interrupt del microprocessore in parole povere).
Le chiamate bloccanti sono le solite chiamate che terminano fatto quello che devono e il chiamate aspetta.


(Se ho capito bene, partiamo da una base nota a tutti).


Non ho mai avuto bisogno di capire (a runtime) se la chiamata che effettuavo era o meno differita. Controllavo se dovevo installare una callback a lavoro terminato per prendere l'eventuale risulto.


Magari se parliamo di un caso specifico e non in termini generici possiamo vedere come fare.


In termini generici, se salvi un semaforo (a database?) che ti dice quando è partita la richiesta differita (il tuo chiamare il metodo differito) con un thread puoi verificare un eventuale timeout e prendere le opportune incazzature via codice.





Stilgar

[DragoRosso]

Era una domanda generica, legata alla situazione storica dove il sapere se un metodo è differito o bloccante poteva essere importante.

In genere non lo è, e usando le tecniche opportune come quelle che hai indicato (io uso spesso anche le funzioni atomiche Interlocked....) si può ovviare all'eventuale differimento.

A runtime ovviamente si sanno già lo cose e quindi difficilmete ci si trova nelle "pesti". E' più un problema progettuale, legato a delle scelte che possono variare in funzione proprio a queste situazioni.

Per chi lavora come me principalmente con Windows, che notoriamente non è un sistema REALTIME, finchè si tratta del proprio codice non ci sono problemi, ma quando si tratta di chiamate S.O. o anche dei componenti dell'ambiente di sviluppo allora mi pongo sempre in stato di allarme.

Io non risparmio i Thread, e ove ho sentore che qualcosa potrebbe avere qualche gabola, uso Waitfor, spin loop o altro a manetta.

Ciao

[DragoRosso]

Faccio un esempio che potrebbe interessare (e riguarda un altro topic già discusso in questo forum).

Il metodo COMMIT (o POST) effettuato su un database è sincrono (cioè bloccante) o differito ?

Le prestazioni di un programma potrebbero essere influenzate da questo particolare. E' anche ovvio che probabilmente "blocco" o "differimento" dipendono dal motore del database e dalla tecnologia usata (non sò sparo a caso, un SQLite magari è bloccante mentre in una architettura Client/Server con MSSQLSERVER è differita).

Io, siccome non posso certo fare prove con tutto, ho preso la decisione di fare le Commit da un Thread, dove verifico anche che non ci siano errori e che il l'eventuale evento "AFTERCOMMIT" sia OK.
In questo modo che il COMMIT sia bloccante o no, non pregiudica ne le tempistiche del mio programma ne eventuali errori.

Ciao
 

[Stilgar]

Allora posso risponderti che ci sono anche i Framework che ci mettono del loro in questi casi 

[DragoRosso]

Allora posso risponderti che ci sono anche i Framework che ci mettono del loro in questi casi 

Ah ah ah, vero. Uno dei più famosi (.NET), per non parlare degli altri che si usano per interfacciarsi con i vari SO, ci mettono tanto del loro.

Per questo almeno io cerco di evitarli il più possibile.

In campo industriale ce ne sono diversi, e hanno tutti queste problematiche (e per quello che sono sensibile all'argomento del TOPIC). Non si sà di preciso come operino, e tu quando ti interfacci devi solo confidare che il tutto funzioni come pensi e speri. Salvo che poi con l'esperienza non poni dei rimendi generali a priori.

Ciao