Tra le novità più importanti di Windows Phone 7.1 è presente la possibilità di eseguire task in background, con l'applicazione attiva o spenta, dando la possibilità di aggiornare tile, eseguire attività di rete, sincronizzare e così via. E' bene sapere che l'applicazione e il task vengono eseguiti in due processi diversi, ma condividono lo stesso deployment e quindi lo stesso isolated storage per poter memorizzare file, immagini o database.
Si tratta di un dettaglio non di poco conto, perché l'applicazione e il task potrebbero essere eseguiti contemporaneamente e accedere a risorse condivise, come appunto l'isolated storage. In questo caso è importante quindi sincronizzare l'accesso ai dati, in modo che solo un codice per volta intervenga su di esso, evitando conflitti. Poiché i processi sono differenti, non è possibile utilizzare le normali keyword lock (c#) e SyncLock (VB), perché si basano su riferimenti di oggetti. E' stata introdotta quindi una nuova classe di nome Mutex, presa in prestito dal .NET Framework, per rappresentare un semaforo cross process.
Nello script seguente viene mostrato un tipico snippet di codice da utilizzare per racchiudere l'accesso allo storage, da usare sia nell'applicazione che nel task.
using (Mutex mutex = new Mutex(false, "accessFile")) { if (mutex.WaitOne(TimeSpan.FromSeconds(5))) { // Accesso esclusivo, nessuna concorrenza try { WriteFileToStorage(); } finally { // Rilascio il mutex mutex.ReleaseMutex(); } } else { // Accesso non ottenuto in cinque secondi } }
Del codice si può notare come il semaforo si identifichi tramite stringa, perciò è possibile usarne più di uno, purché si condivida la stessa chiave. Il parametro booleano indica se il thread corrente deve acquisire la ownership, ma in questo caso non si vuole questo effetto. Il metodo WaitOne permette di aspettare che il semaforo si liberi indicando facoltativamente il tempo massimo di attesa. Nell'esempio, passati i 5 secondi si ottiene true se il semaforo è stato rilasciato entro il tempo massimo, oppure false in caso contrario. Una volta ottenuto l'accesso si detiene il mutex e si è al sicuro da accessi concorrenti. Terminate le operazioni è necessario quindi rilasciare il mutex, così da permette ad un altro thread/processo di accedere.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Utilizzare Azure Cosmos DB con i vettori
Gestione degli stili CSS con le regole @layer
Applicare un filtro per recuperare alcune issue di GitHub
Estrarre dati randomici da una lista di oggetti in C#
Migliorare i tempi di risposta di GPT tramite lo streaming endpoint in ASP.NET Core
Utilizzare Azure AI Studio per testare i modelli AI
Utilizzare un numero per gestire la concorrenza ottimistica con SQL Server ed Entity Framework
Simulare Azure Cosmos DB in locale con Docker
Change tracking e composition in Entity Framework
Gestire la cancellazione di una richiesta in streaming da Blazor
Creare un webhook in Azure DevOps
Gestire eccezioni nei plugin di Semantic Kernel in ASP.NET Core Web API
I più letti di oggi
- Eseguire query in contemporanea con EF
- Fissare una versione dell'agent nelle pipeline di Azure DevOps
- .NET Aspire per applicazioni distribuite
- Utilizzare Locust con Azure Load Testing
- Autenticazione di git tramite Microsoft Entra ID in Azure DevOps
- Repaint, Reflow e Compositing: Come Funziona il Rendering nel Browser
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!