Come documentare le prove logiche contro le condizioni di gara?

3

Sfondo specifico

Sto scrivendo una libreria per estendere la dorsale asincrona di una lingua con il multitasking cooperativo. (La lingua è Hack , ma C # implementa anche async-await con Task , se il concetto suona familiare.) Sono stato in grado di esprimere che intendo fare in codice nella libreria. Il problema dell'ora è quando .

Alcune caratteristiche della lingua hanno comportamenti ben definiti rispetto all'ordine. Ho bisogno di questo per mettere i limiti nel tempo quando le cose hanno una probabilità non netta di ripresa dopo aver ceduto il controllo (tramite await ). Tuttavia, lo scheduler sottostante è opaco al programma. Tranne un meccanismo molto debole per spingere sul retro dello scheduler ( \HH\Asio\later() ), quando molte attività sono completate contemporaneamente, il controllo potrebbe tornare a qualsiasi codice in attesa di uno di essi. questa è una ricetta perfetta per le condizioni di gara e l'ho già scoperta nel modo più duro.

Ho scritto qualcosa di specifico per descrivere le proprietà di ordinamento che voglio. So che le garanzie che derivano da tutti i comportamenti ben definiti insieme sono abbastanza forti da rafforzarla. Tuttavia, il modo più naturale che ho trovato per propagare le garanzie è la prova logica. Non sono sicuro, propenso a dubitare, che la struttura del codice da sola possa comunicare le garanzie di ordinamento, poiché l'azione delle proprietà ben definite è di natura globale, che accoppia una quantità di codice scomoda insieme.

Problema generale

Voglio scrivere la documentazione che delinea le prove di ordinamento temporale che si basano su proprietà ben definite di costrutti linguistici. Perché il comportamento indefinito è proprio questo - non definito - e perché nel mio caso lo scheduler è opaco, i test non dicono molto. La propagazione delle garanzie è strongmente accoppiata all'implementazione; i test potrebbero passare sulla fortuna.

Questo è l'argomento delle altre domande e il consenso sembra tra cui:

  1. Non testare
  2. Prying apre lo scheduler e verifica

Quest'ultimo non è un'opzione qui, ma per integrare il primo, ho delle prove delle caratteristiche delle mie specifiche, data l'implementazione che ho scritto (aiuta che async-await è più limitato del multithreading gratuito). Tuttavia, sono preoccupato che questo approccio alla documentazione sia inaccettabilmente fragile perché è troppo strettamente collegato all'implementazione.

Se questo è un approccio praticabile, come posso ridurre al minimo la fragilità? Se no, c'è un esempio o una risorsa a cui posso guardare dove il codice è abbastanza espressivo da solo?

    
posta concat 05.03.2017 - 04:40
fonte

1 risposta

1

In primo luogo, vorrei documentare la libreria come faresti con qualsiasi altra API pubblica: usando le descrizioni delle astrazioni e dei membri. Cerca di includere una sezione introduttiva con esempi su come utilizzare la tua libreria.

In secondo luogo, aggiungerei alla sezione di riferimento le informazioni necessarie ad altri sviluppatori per creare le proprie prove informali quando si utilizza la libreria: pre-condizioni, post-condizioni e invarianti.

Infine, in un'appendice, puoi includere le prove. Se si tratta di prove formali, è difficile evitare di dipendere interamente dall'implementazione. Se si tratta di prove informali, potresti essere in grado di basarle su pre-condizioni, post-condizioni e invarianti utilizzati nella tua implementazione. Questo sarà meno dettagliato e meno fragile delle prove basate su ogni riga di codice nell'implementazione.

Infine, potresti voler cercare un verificatore automatico di prove che puoi usare.

    
risposta data 07.03.2017 - 17:18
fonte