Visualizzazione dei risultati da 1 a 6 su 6
  1. #1

    [Delphi] Gestione Semafori

    Alka credo che solo tu puoi rispondere (senza offesa per gli altri).

    devo realizzare un sistema di semafori per consentire l'accesso o meno ad alcune tabelle (dbf).

    Fino ad ora ho un sistema con un file ini, ma forse è meglio usare i semafori di windows.

    Hai conoscenze in merito?

    se vuoi possiamo parlarne anche via email, il mio indirizzo lo trovi nel tuo guest-book.

    ciao

  2. #2
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    24,296

    Mutex

    Se parliamo dell'argomento qui, forse è più comodo e potrebbe servire ad altri programmatori che si trovano nella medesima situazione.

    Non ho capito bene il legame tra i database DBF, i file INI e i semafori...ad ogni modo.......

    Ho a che fare spesso con gli elementi di sincronizzazione di Delphi poichè realizzo frequentemente applicazioni multithread che comunicano con dispositivi esterni e visualizzano dati. Per fare in modo che i differenti thread di esecuzione del programma non interferiscano tra loro quando accedono alle medesime risorse globali, faccio uso dei cosiddetti mutex.

    Si tratta di richiamare alcune funzioni API (CreateMutex, ReleaseMutex...) in modo da creare questi oggetti. Lavorando in multithreading, ciascun percorso dell'applicazione deve cercare di "prendere" il mutex prima di accedere alle risorse globali; al termine del loro uso, il mutex viene rilasciato e reso disponibile ai thread rimanenti che possono prenderne a loro volta il possesso e elaborare nuovamente le variabili globali dell'applicazione.

    Da quel che ricordo, mi sembra che tu abbia avuto già esperienza con le funzioni API in genere, quindi credo che tu possa comprendere benissimo il funzionamento del meccanismo semplicemente leggendo la Guida in Linea di Delphi.

    Oltre ai mutex, Windows offre anche i cosiddetti semaphores: sono molto simili ai mutex, ma incorporano una specie di contatore.

    Sinceramente, non ho ben capito l'ambito in cui intendi far uso di queste strutture di sincronizzazione, quindi non posso dirti se funzioneranno egregiamente. Magari scrivi qualche indicazione in più.

    Per quanto riguarda i database, credo che le librerie di accesso ai dati abbiano già al loro interno dei meccanismi di blocco/sblocco di singoli record e/o colonne quando vengono modificati da più applicazioni contemporaneamente. Potresti forse contemplare il passaggio ad un formato di database più robusto di quello che stai utilizzando ora.

    Se hai bisogno di altre indicazioni, scrivi.

    Ciao!
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Home | Blog | Delphi Podcast | Twitch | Altro...

  3. #3
    grazie, ora ti spiego meglio, forse esiste una soluzione migliore.

    io ho la necessità di impedire l'accesso ad alcune funzioni (per funzione intendo un modulo, come ad es. gestione magazzino) del programma se c'è già un utente che le sta utilizzando.
    Fino ad adesso utilizzo un file ini in cui metto un flag per indicare se la funzione è disponibile o no e quando ci entro blocco il flag.
    Il problema è che se per qualche motivo si blocca l'applicazione resta il flag attivo e quindi nessuno può entrare nella funzione.

    Io utilizzo i dbf, dovrei usare qualcosa di più robusto ma deve essere pianificato con calma il porting.

    Ritornando al problema, ho provato ad aprire una tabella fittizia in modo esclusivo (abbolendo il file ini) ma se l'applicazione viene terminata in modo anomalo il problema del blocco rimane fino a quando non si riavvia il pc o si fa una ricostruzione archivi.

    La cosa migliore sarebbe quella di prevedere le possibili anomalie e proteggerle, ma la cosa non è semplice in quando i problemi vengono da degli eseguibili dos di cui non ne sono proprietario.

    Pensavo ai semafori ipotizzando che nel momento in cui l'applicazione si chiude questi vengano automaticamente distrutti, quindi in teoria si risolve automaticamente tutto.

    Considera che il mio programma viene utilizzato in rete quindi i "semafori" dovrebbero essere visibili anche dai clients.

    Grazie per la pasienza.

    Se non mi sono spiegato bene... cercherò di spiegarmi meglio.

  4. #4
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    24,296

    Gestione di più utenti che accedono ai dati

    Avevo pressapoco capito la problematica, ma pensavo si riferisse ad applicazioni residenti sulla stessa macchina.

    In questo caso, come hai detto tu, diventa effettivamente molto difficile gestire manualmente un meccanismo di blocco in modo sicuro ed efficiente. Il problema che indice maggiormente è quello della terminazione anomala delle applicazioni.

    Forse potresti predisporre un'applicazione, o meglio un servizio in grado di monitorare gli accessi. Questo servizio, attivo sul server, raccoglie le richieste di accesso ai dati da parte delle applicazioni. Ciascuna applicazione fa la richiesta al servizio in qualche modo per sapere se un'altra applicazione sta utilizzando i dati; in caso negativo, prende il possesso di questo "semaforo virtuale centralizzato" e opera sui dati. Magari si potrebbe dotare ogni applicazione di un thread che invii notifiche di presenza al servizio; quando l'applicazione viene terminata in modo anomalo, anche il thread di presenza si interrompe...passati n minuti dall'ultima notifica, il servizio potrebbe rilasciare il blocco sui dati eventualmente posseduto da quella applicazione.

    Questa è solo un'idea ovviamente...certo che implementare una cosa simile non è facile! Secondo me, considerando le fasi di sviluppo e di test, faresti prima a valutare un eventuale porting dei tuoi database in un formato che sia in grado di gestire più utenti (InterBase è in grado di farlo).

    Ciao!
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Home | Blog | Delphi Podcast | Twitch | Altro...

  5. #5
    grazie, passare a interbase è già nell'aria ma cmq non mi risolve il problema in quanto a me non serve un multiaccesso, ma solo consentire l'accesso ad un utente alla volta.

    cmq adesso vedo un pò...

    tu che gestore mi consigli? considera che l' archivio principale ha 400.000 record e uno collegato ne ha pochi in meno.

  6. #6
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    24,296
    Il fatto che InterBase supporti più utenti connessi al database significa anche che è possibile gestirli tramite trigger e stored procedure utilizzando parole chiave particolari integrate nel linguaggio SQL.

    Ad esempio, potresti collegarti ad un database IB e reperire dati da una tabella attraverso una stored procedure; la procedura può controllare gli utenti collegati e decidere se restituire i dati cercati oppure generare un'eccezione e quindi impedirne l'accesso.

    In breve, il tuo scopo di "bloccaggio degli utenti" rientra nelle possibilità della gestione multiutenza dei database, quindi ti serve necessariamente un database che sia in grado di implementarla. InterBase fornisce il supporto; non ho mai utilizzato SQL Server oppure Oracle, ma sono quasi certo che tutti questi gestori di database, celebri per la loro rinomata potenza, supportino la multiutenza.

    Fai la tua scelta considerando anche i formati con cui sei abituato a lavorare.

    Magari apri una nuova discussione generica sui database, visto che questo problema non è specifico dell'ambiente Delphi, ma si trova "a monte"...probabilmente altri partecipanti ti sapranno dare indicazioni più utili ed esaustive in base alla loro esperienza.

    Ciao!
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Home | Blog | Delphi Podcast | Twitch | Altro...

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.