Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce
Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce
REDMI Note 17 Pro porta in fascia media una batteria da 8.340 mAh con ricarica HyperCharge a 67W, un display AMOLED da 6,83 pollici capace di picchi di luminosità molto elevati e una struttura certificata TÜV SÜD contro cadute e infiltrazioni d'acqua, il tutto racchiuso in una scocca da 223 grammi. Lo abbiamo provato per diversi giorni tra fotocamera, prestazioni, autonomia e prezzo sul mercato italiano
Insta360 Luna Ultra: la potenza del sensore da 1 pollice incontra la portabilità estrema
Insta360 Luna Ultra: la potenza del sensore da 1 pollice incontra la portabilità estrema
Insta360 Luna Ultra integra un sensore da 1 pollice 8K, ottiche Leica e triplo chip IA. Tra schermo OLED rimovibile, workflow I-Log a 10 bit e stabilizzazione a tre assi, analizziamo le doti tecniche di una gimbal camera pensata per i professionisti
Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa
Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa
Marvel's Wolverine porta Logan in un'avventura inedita, violenta e fortemente narrativa, costruita attorno alla sua natura di combattente e al difficile rapporto con il proprio passato. Insomniac Games punta su combattimenti spettacolari, progressione e personalizzazione, inserendo l'azione in un mondo segnato dalla persecuzione dei mutanti. Un viaggio intenso, che alterna mattanza, esplorazione e momenti sorprendentemente emotivi.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 20-05-2015, 16:39   #1
Androidiano93
Junior Member
 
Iscritto dal: Sep 2011
Messaggi: 29
[JAVA]Delucidazioni su signal, notify e -All

Salve a tutti, avrei delle domande da porvi, grazie. Anche se a volte si capisce da come parlo, non specifico se sto parlando di monitor nativi o Lock e Condition, perchè suppongo che usino le stesse politiche per ciò che chiedo.

1) Supponiamo che io abbia un metodo che sta eseguendo codice utile e POI viene messo in attesa a causa di una condizione. Quando viene risvegliato ed effettivamente rimesso in esecuzione, ricomincia da capo oppure il lavoro che aveva compiuto prima lo ha salvato, così può ricominciare dall'istruzione successiva alla wait/await?

2)Non ho capito proprio le differenze nei casi in cui bisogna fare signal e quando signalAll. Ho capito che nel primo caso se ne sveglia uno non determinabile a priori e che se ne voglio uno preciso devo fare certi controlli e mal che vada rimettere in attesa quelli che non coincidono con quello che sto cercando. Ma a questo punto non è meglio usare sempre singalAll?

Mi spiego: prendiamo in considerazione il classico problema del produttore/consumatore con buffer limitato. (Se tento di inserire oltre la dimensione massima -> attendo, stessa cosa se prelevo a vuoto) Parte il programma e:
- Arriva un consumatore (a vuoto) e va nella sua attesa per la sua condizione
- Altro consumatore, idem
- Altro consumatore, idem
- Ora arriva un produttore. Se fa una signal, uno di quei consumatori si sveglia, appena disponibile prende il lock e fa quello che deve fare, e si rimuove dalla coda. Se fa una signalAll, si svegliano TUTTI, SOLO UNO riesce ad acquisire il lock e tutti gli altri si ritrovano in attesa (credo di aver capito che così funzioni la questione). Io allora mi chiedo, quando usare signal/notify e quando signalAll/notifyAll? Forse nel caso in cui voglio seguire un certo ordine di esecuzione sveglio TUTTI, consulto una mia struttura dati (es. una coda) e rimetto immediatamente a dormire i thread che non coincidono con l'elemento che desidero io all'interno della mia struttura; mentre con una notify/signal dovrei essere fortunato a beccare quanto prima quello giusto? Questa è la mia intuizione, anche se noto ancora una certa supremazia delle -All a livello di utilità, illuminatemi su questi due punti per cortesia, grazie di cuore!
Androidiano93 è offline   Rispondi citando il messaggio o parte di esso
Old 21-05-2015, 14:26   #2
sottovento
Senior Member
 
L'Avatar di sottovento
 
Iscritto dal: Nov 2005
Città: Texas
Messaggi: 1722
Quote:
Originariamente inviato da Androidiano93 Guarda i messaggi
Salve a tutti, avrei delle domande da porvi, grazie. Anche se a volte si capisce da come parlo, non specifico se sto parlando di monitor nativi o Lock e Condition, perchè suppongo che usino le stesse politiche per ciò che chiedo.

1) Supponiamo che io abbia un metodo che sta eseguendo codice utile e POI viene messo in attesa a causa di una condizione. Quando viene risvegliato ed effettivamente rimesso in esecuzione, ricomincia da capo oppure il lavoro che aveva compiuto prima lo ha salvato, così può ricominciare dall'istruzione successiva alla wait/await?
Dalla istruzione successiva. Se ci pensi, suona logico...


Quote:
Originariamente inviato da Androidiano93 Guarda i messaggi
2)Non ho capito proprio le differenze nei casi in cui bisogna fare signal e quando signalAll. Ho capito che nel primo caso se ne sveglia uno non determinabile a priori e che se ne voglio uno preciso devo fare certi controlli e mal che vada rimettere in attesa quelli che non coincidono con quello che sto cercando. Ma a questo punto non è meglio usare sempre singalAll?
Esatto! Se sei indeciso, usa signalAll()

Quote:
Originariamente inviato da Androidiano93 Guarda i messaggi
Mi spiego: prendiamo in considerazione il classico problema del produttore/consumatore con buffer limitato. (Se tento di inserire oltre la dimensione massima -> attendo, stessa cosa se prelevo a vuoto) Parte il programma e:
- Arriva un consumatore (a vuoto) e va nella sua attesa per la sua condizione
- Altro consumatore, idem
- Altro consumatore, idem
- Ora arriva un produttore. Se fa una signal, uno di quei consumatori si sveglia, appena disponibile prende il lock e fa quello che deve fare, e si rimuove dalla coda. Se fa una signalAll, si svegliano TUTTI, SOLO UNO riesce ad acquisire il lock e tutti gli altri si ritrovano in attesa (credo di aver capito che così funzioni la questione). Io allora mi chiedo, quando usare signal/notify e quando signalAll/notifyAll? Forse nel caso in cui voglio seguire un certo ordine di esecuzione sveglio TUTTI, consulto una mia struttura dati (es. una coda) e rimetto immediatamente a dormire i thread che non coincidono con l'elemento che desidero io all'interno della mia struttura; mentre con una notify/signal dovrei essere fortunato a beccare quanto prima quello giusto? Questa è la mia intuizione, anche se noto ancora una certa supremazia delle -All a livello di utilità, illuminatemi su questi due punti per cortesia, grazie di cuore!
L'esempio calza alla perfezione. Va da se che la signalAll() genera piu' overhead (e' meno efficiente, visto che si fanno delle operazioni in piu' rispetto alla signal()), ma si tratta di dettagli
__________________
In God we trust; all others bring data
sottovento è offline   Rispondi citando il messaggio o parte di esso
Old 24-05-2015, 13:44   #3
Androidiano93
Junior Member
 
Iscritto dal: Sep 2011
Messaggi: 29
Grazie mille per le delucidazioni, il topic si può chiudere
Androidiano93 è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce Recensione REDMI Note 17 Pro: il midrange con ba...
Insta360 Luna Ultra: la potenza del sensore da 1 pollice incontra la portabilità estrema Insta360 Luna Ultra: la potenza del sensore da 1...
Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa Marvel's Wolverine, la recensione: Logan torna p...
DJI Romo 2: tante novità lo rendono un robot completo DJI Romo 2: tante novità lo rendono un ro...
Sony Bravia 9 II: il True RGB alla prova, dove l'LCD sfida l'OLED Sony Bravia 9 II: il True RGB alla prova, dove l...
ROG Cronox: ASUS alza l'asticella dei ca...
Lenovo annuncia nuovi sistemi per la vir...
M6 e M5 Ultra, i primi benchmark conferm...
La nuova falla della cybersecurity &egra...
The Blood of Dawnwalker, il sequel potre...
Colpiti i data center Amazon: irrecupera...
Google Wallet, nuova interfaccia in arri...
iPhone Duo, problemi di produzione per i...
Firefox diventa più veloce con PDF e JPE...
WhatsApp, arriva su iOS la nuova scorcia...
Snap presenta Specs: realtà aumentata, c...
SteamOS verso un cambiamento epocale: ar...
Recensione HUAWEI FreeBuds Neo, piccoli ...
TSMC aumenta i costi di produzione: AMD ...
L'Europa sfida i magnati dei combustibil...
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: 18:16.


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