Torna indietro   Hardware Upgrade Forum > Software > Programmazione

MSI PRO MAX EDGE AI+, Ryzen AI Max+ 395 e 128 GB per far girare in locale anche i modelli più grandi
MSI PRO MAX EDGE AI+, Ryzen AI Max+ 395 e 128 GB per far girare in locale anche i modelli più grandi
Abbiamo provato MSI PRO MAX EDGE AI+, un mini-PC professionale progettato per eseguire modelli di intelligenza artificiale in locale, senza dipendere dal cloud. Il sistema abbina il processore AMD Ryzen AI Max+ 395, 128 GB di memoria unificata e un telaio in alluminio da appena 4 litri, con l'obiettivo di offrire capacità di elaborazione elevate in un formato compatto.
Recensione vivo X500 Pro Max: la fotografia mobile ha un nuovo protagonista
Recensione vivo X500 Pro Max: la fotografia mobile ha un nuovo protagonista
Il nuovo top di gamma vivo punta su un comparto fotografico particolarmente articolato, con un teleobiettivo da 200 megapixel e teleconvertitori esterni capaci di arrivare a 400 mm equivalenti. Lo abbiamo provato a Tenerife, mettendo alla prova fotocamere, prestazioni, autonomia e accessori. Ecco come si è comportato.
WoW Forever: la beta è stato uno dei momenti più alti della storia dei videogiochi, e non si ripeterà
WoW Forever: la beta è stato uno dei momenti più alti della storia dei videogiochi, e non si ripeterà
Un mondo affollato e vivo, personaggi destinati a sparire a fine test e nessuno a inseguire l'oggetto giusto. Beta e stress test di World of Warcraft: Forever hanno fatto emergere un roleplay spontaneo, tra danze a Goldshire e code ordinate ai PNG
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 02-02-2009, 11:43   #1
gpnet
Junior Member
 
Iscritto dal: Aug 2008
Messaggi: 25
[C#] Filestream - problema con lock-unlock

Ciao a tutti ,
Stavo cercando aiuto ad un problema strano che mi capita usando l'oggetto filestream. In particolare avevo bisogno di condividere un file fra diversti utenti e cosi ho codificato queste linee di codice che qui riporto in parte per facilità di lettura :



Codice:
. . .
. . .  
public enum 	dbLockType	{ _none =0, _lock, _unLock, _default}
long lockPos = -1;
long lockRec = -1;
 
  FileStream DtFile = new FileStream(@"\\server\d\folder\test.txt", FileMode.Open, FileAccess.ReadWrite, FileShare.ReadWrite,8000); 
. . .
. . .

public bool getBufferFromDisk(long RecordNumber, byte[] toArray, int startingAt, int length, dbLockType dbLock)
{
  long seekPosition = GetFilePos(RecordNumber);
  try {
	DtFile .Seek(seekPosition, System.IO.SeekOrigin.Begin);
	DtFile .Read(toArray, startingAt, length);
	if ( dbLock == dbLockType._lock) {
  	   if ( lockPos > -1)
		DtFile .Unlock(lockPos, blockSize);  // unlock previous locks
	   DtFile .Lock(seekPosition, blockSize); 
	   
	   lockPos = seekPosition;
	   lockRec = RecordNumber;
	}
  }
  catch(IOException e) {
	return false;	
  }
  return true;
}
nella main il primo utente esegue la funzione getBufferFromDisk con questi parametri :

getBufferFromDisk(8, toArray, 500, 100, dbLock);

in questo modo legge e blocca il filestream alla pos 500 per 100 bytes.


Il secondo utente lo stesso pgm da una altro PC e cerca di eseguire la stessa funzione con i seguenti parametri:
getBufferFromDisk(0, toArray, 0, 100, dbLock);

è in questo punto che viene gererato l'errore di lettura a questa specifica.

DtFile .Read(toArray, startingAt, length);

così ho inserito il blocco Try-catch per protezione.
Strano , ho pensato, perchè il primo utente ha bloccato 100 bytes a partire dalla pos 500 e non dalla Pos 0.

Dopo un po di googling ho trovato questo articolo che forse riprende il mio caso : http://www.devnewsgroups.net/group/m...opic15633.aspx

Così ho giocato un po per capire meglio il problema e ho trovato che :
1. anche se viene modificata la lettura in .Read ( tenendo il primo user con il pgm aperto e la pos loccata ) il secondo utente trova sempre la posizione 0 loccata.
2. Il lock è esteso all'intero buffer , che è di 8K.
3. Tutto questo è vero se il secondo utente cerca di leggere qualcosa in questo buffer se qualcosa in questo buffer è loccato , altrimenti tutto fila liscio senza exceptions. Voglio dire che se il primo user locca qualcosa alla posizione 8500 , 100 il secondo utente che legge alla pos. 0 non ha nessun problema.

Cosa è questo ? , un bug? Sto sbagliando io qualcosa nella codifica o che cosa? E' questo il modo corretto di lavorare con lock e unlock

Qualcuno può aiutarmi a risolvere il problema

grazie a tutti ,

JossGP
gpnet è offline   Rispondi citando il messaggio o parte di esso
Old 04-02-2009, 23:34   #2
eve
Senior Member
 
Iscritto dal: Apr 2005
Città: Padova
Messaggi: 1156
Quote:
Originariamente inviato da gpnet Guarda i messaggi
Ciao a tutti ,
Stavo cercando aiuto ad un problema strano che mi capita usando l'oggetto filestream. In particolare avevo bisogno di condividere un file fra diversti utenti e cosi ho codificato queste linee di codice che qui riporto in parte per facilità di lettura :



Codice:
. . .
. . .  
public enum 	dbLockType	{ _none =0, _lock, _unLock, _default}
long lockPos = -1;
long lockRec = -1;
 
  FileStream DtFile = new FileStream(@"\\server\d\folder\test.txt", FileMode.Open, FileAccess.ReadWrite, FileShare.ReadWrite,8000); 
. . .
. . .

public bool getBufferFromDisk(long RecordNumber, byte[] toArray, int startingAt, int length, dbLockType dbLock)
{
  long seekPosition = GetFilePos(RecordNumber);
  try {
	DtFile .Seek(seekPosition, System.IO.SeekOrigin.Begin);
	DtFile .Read(toArray, startingAt, length);
	if ( dbLock == dbLockType._lock) {
  	   if ( lockPos > -1)
		DtFile .Unlock(lockPos, blockSize);  // unlock previous locks
	   DtFile .Lock(seekPosition, blockSize); 
	   
	   lockPos = seekPosition;
	   lockRec = RecordNumber;
	}
  }
  catch(IOException e) {
	return false;	
  }
  return true;
}
nella main il primo utente esegue la funzione getBufferFromDisk con questi parametri :

getBufferFromDisk(8, toArray, 500, 100, dbLock);

in questo modo legge e blocca il filestream alla pos 500 per 100 bytes.


Il secondo utente lo stesso pgm da una altro PC e cerca di eseguire la stessa funzione con i seguenti parametri:
getBufferFromDisk(0, toArray, 0, 100, dbLock);

è in questo punto che viene gererato l'errore di lettura a questa specifica.

DtFile .Read(toArray, startingAt, length);

così ho inserito il blocco Try-catch per protezione.
Strano , ho pensato, perchè il primo utente ha bloccato 100 bytes a partire dalla pos 500 e non dalla Pos 0.

Dopo un po di googling ho trovato questo articolo che forse riprende il mio caso : http://www.devnewsgroups.net/group/m...opic15633.aspx

Così ho giocato un po per capire meglio il problema e ho trovato che :
1. anche se viene modificata la lettura in .Read ( tenendo il primo user con il pgm aperto e la pos loccata ) il secondo utente trova sempre la posizione 0 loccata.
2. Il lock è esteso all'intero buffer , che è di 8K.
3. Tutto questo è vero se il secondo utente cerca di leggere qualcosa in questo buffer se qualcosa in questo buffer è loccato , altrimenti tutto fila liscio senza exceptions. Voglio dire che se il primo user locca qualcosa alla posizione 8500 , 100 il secondo utente che legge alla pos. 0 non ha nessun problema.

Cosa è questo ? , un bug? Sto sbagliando io qualcosa nella codifica o che cosa? E' questo il modo corretto di lavorare con lock e unlock

Qualcuno può aiutarmi a risolvere il problema

grazie a tutti ,

JossGP
Non è un bug o meglio non credo che sia un bug. A mio avviso dovrebbe essere la dimensione del cluster sul hard disk. Fai delle prove. Semplicemente prendi una memoria usb. Lo formatti con una certa dimensione di cluster, crea un file e lancia il programma. Poi lo formatti con un cluster più grande e prova e vai avantio cosi'.....se vedi differenze nel comportamento allora è proprio la dimensione del cluster altrimenti non mi viene niente in mente
__________________
THUG-LIFE
eve è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


MSI PRO MAX EDGE AI+, Ryzen AI Max+ 395 e 128 GB per far girare in locale anche i modelli più grandi MSI PRO MAX EDGE AI+, Ryzen AI Max+ 395 e 128 GB...
Recensione vivo X500 Pro Max: la fotografia mobile ha un nuovo protagonista Recensione vivo X500 Pro Max: la fotografia mobi...
WoW Forever: la beta è stato uno dei momenti più alti della storia dei videogiochi, e non si ripeterà WoW Forever: la beta è stato uno dei mome...
Oracle AI World 2026: in Europa prima la sovranità, poi la sicurezza e solo dopo l'IA Oracle AI World 2026: in Europa prima la sovrani...
DS N°7 E-Tense: il SUV premium made in Melfi che punta su autonomia e comfort DS N°7 E-Tense: il SUV premium made in Melfi...
Contatori del condominio, la data da seg...
Windows 11, 8 GB di RAM non sono pi&ugra...
Octopus Energy ritira la tariffa Flex Mu...
Disegnare la superconduttività co...
Il razzo spaziale NASA SLS per la missio...
Il drone NASA Dragonfly ha volato per la...
GTA 6, preload dal 10 novembre: servono ...
The Elder Scrolls VI: Sentinel, Bethesda...
Un doppio disco di detriti attorno a una...
Windows 11: risolta la disattivazione fo...
42AI, l'intelligenza artificiale anticip...
Windows 11 26H2 gira con appena 128 MB d...
GPT-6.2 Astra compare in Codex, Claude F...
Record assoluto per Linux 7.4: quasi mez...
Datacenter “standard” esonerato dalla va...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 02:25.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Served by www3v