Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Google Pixel 10 è compatto e ha uno zoom 5x a 899€: basta per essere un best-buy?
Google Pixel 10 è compatto e ha uno zoom 5x a 899€: basta per essere un best-buy?
Google Pixel 10 è uno smartphone che unisce una fotocamera molto più versatile rispetto al passato grazie allo zoom ottico 5x, il supporto magnetico Pixelsnap e il nuovo chip Tensor G5. Il dispositivo porta Android 16 e funzionalità AI avanzate come Camera Coach, mantenendo il design caratteristico della serie Pixel con miglioramenti nelle prestazioni e nell'autonomia. In Italia, però, mancano diverse feature peculiari basate sull'AI.
Prova GeForce NOW upgrade Blackwell: il cloud gaming cambia per sempre
Prova GeForce NOW upgrade Blackwell: il cloud gaming cambia per sempre
L'abbonamento Ultimate di GeForce NOW ora comprende la nuova architettura Blackwell RTX con GPU RTX 5080 che garantisce prestazioni tre volte superiori alla precedente generazione. Non si tratta solo di velocità, ma di un'esperienza di gioco migliorata con nuove tecnologie di streaming e un catalogo giochi raddoppiato grazie alla funzione Install-to-Play
Ecovacs Deebot X11 Omnicyclone: niente più sacchetto per lo sporco
Ecovacs Deebot X11 Omnicyclone: niente più sacchetto per lo sporco
Deebot X11 Omnicyclone implementa tutte le ultime tecnologie Ecovacs per l'aspirazione dei pavimenti di casa e il loro lavaggio, con una novità: nella base di ricarica non c'è più il sacchetto di raccolta dello sporco, sostituito da un aspirapolvere ciclonico che accumula tutto in un contenitore rigido
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 10-07-2007, 22:51   #1
osa
Senior Member
 
L'Avatar di osa
 
Iscritto dal: Dec 2004
Città: Napoli
Messaggi: 342
[JAVA]Servlet e synchronized

Salve ho creato una servlet, dentro la quale c'è un blocco synchronized su un oggetto (un campo della classe).
Ecco il codice:
Codice:
Object mutex=new Object();
synchronized(mutex){
if ( cond == true){
Thread t=new ExecuteThred(); //è un thread da me creato
t.start(); 
}
}
Voglio che sotto determinate condizioni una sola istanza delle servlet in esecuzione crei il thread (ci deve essere in esecuzione un solo thread ExecuteThread ).
Voglio chiedervi se il "mutex" devo dichiarlo come campo della classe (private Object mutex) o tale oggetto deve essere sostituito con ExecuteThread().
Grazie.
__________________
Il futuro lo conoscerete quando sarà arrivato, prima di allora dimenticatelo.
(Eschilo)
osa è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 12:19   #2
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
Premetto che se l'applicazione non è distributable, il server usa una sola istanza della classe servlet per rispondere a tutte le richieste (SRV2.2).

Un blocco sincronizzato su un monitor non condiviso equivale ad un blocco non sincronizzato. Non essendo il monitor condiviso non è infatti possibile che due Thread se lo contendano.

Una variabile locale non è condivisa per definizione.

Dunque questo:

Codice:
metodo() {
    Object monitor = new Object();
    synchronized(monitor) {
        fai qualcosa
    }
}
equivale a:

Codice:
metodo() {
    fai qualcosa;
}
Se il monitor è condiviso allora la sincronizzazione stabilisce una mutua esclusione tra i condividenti. Un campo è condiviso. Dunque:

Codice:
private final Object monitor = new Object();

metodo() {
    synchronized(monitor) {

    }
}
effettivamente esclude che due Thread possano entrare nel blocco in contemporanea.

Occhio che se cond è un campo delle istanze della tua servlet allora esiste la possibilità che siano creati più ExecutorThread.
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 17:37   #3
osa
Senior Member
 
L'Avatar di osa
 
Iscritto dal: Dec 2004
Città: Napoli
Messaggi: 342
Quote:
Originariamente inviato da PGI-Bis Guarda i messaggi
Premetto che se l'applicazione non è distributable, il server usa una sola istanza della classe servlet per rispondere a tutte le richieste (SRV2.2).

Un blocco sincronizzato su un monitor non condiviso equivale ad un blocco non sincronizzato. Non essendo il monitor condiviso non è infatti possibile che due Thread se lo contendano.

Una variabile locale non è condivisa per definizione.

Dunque questo:

Codice:
metodo() {
    Object monitor = new Object();
    synchronized(monitor) {
        fai qualcosa
    }
}
equivale a:

Codice:
metodo() {
    fai qualcosa;
}
Se il monitor è condiviso allora la sincronizzazione stabilisce una mutua esclusione tra i condividenti. Un campo è condiviso. Dunque:

Codice:
private final Object monitor = new Object();

metodo() {
    synchronized(monitor) {

    }
}
effettivamente esclude che due Thread possano entrare nel blocco in contemporanea.

Occhio che se cond è un campo delle istanze della tua servlet allora esiste la possibilità che siano creati più ExecutorThread.
Quindi Object mutex devo dichiarlo come campo. La condizione "cond" è la seguente t.getstate().TERMINATED, dove t è un oggetto ExecuteThread, ovvero controllo che il thread sia terminato, in caso affermativo ne avvio un altro, la cosa importante è che ci sia solo un thread ExecuteThread in esecuzione. L'oggetto t è un campo della classe. Però non capisco, da quello che mi hai detto, perchè se la condizione è un campo possono essere creati più thread.
__________________
Il futuro lo conoscerete quando sarà arrivato, prima di allora dimenticatelo.
(Eschilo)

Ultima modifica di osa : 11-07-2007 alle 17:39.
osa è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 17:50   #4
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
L'unica cosa che devi assicurare è che la condizione usata per "capire" se esista già un ExecutorThread permanga a prescindere dal numero di istanze della servlet che sono create.

Le specifiche garantiscono l'esistenza di una sola istanza di quella servlet in un certo istante. Non vietano che quell'istanza sia di volta in volta rigenerata.

Ad esempio se dicessimo:

Codice:
class Servlet... {
    private final Object monitor...
    private final AtomicBoolean condition = new AtomicBoolean(false);

    ...servizio
        if(condition) {
             crea un ExecutorThread, condition.set(false);
Ci fregheremmo con le noste mani. Qui condition è false ma solo per l'istanza corrente di Servlet. Se il server rigenerasse questa istanza allora l'esecuzione del servizio troverebbe condition a true e creerebbe un secondo ExecutorThread.

A conti fatti la questione è un semplicemente di "ambito di vita". Devi far sì che la conzione appartenga ad un ambito superiore a quello di esistenza dell'istanza servlet. Perchè è questo solo il "problema": il ciclo di vita di questi oggetti è determinato esternamente al programma che hai per le mani.

Tutto qua.
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!

Ultima modifica di PGI-Bis : 11-07-2007 alle 17:50. Motivo: un false al posto di true
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 18:47   #5
osa
Senior Member
 
L'Avatar di osa
 
Iscritto dal: Dec 2004
Città: Napoli
Messaggi: 342
Quote:
Originariamente inviato da PGI-Bis Guarda i messaggi
L'unica cosa che devi assicurare è che la condizione usata per "capire" se esista già un ExecutorThread permanga a prescindere dal numero di istanze della servlet che sono create.

Le specifiche garantiscono l'esistenza di una sola istanza di quella servlet in un certo istante. Non vietano che quell'istanza sia di volta in volta rigenerata.

Ad esempio se dicessimo:

Codice:
class Servlet... {
    private final Object monitor...
    private final AtomicBoolean condition = new AtomicBoolean(false);

    ...servizio
        if(condition) {
             crea un ExecutorThread, condition.set(false);
Ci fregheremmo con le noste mani. Qui condition è false ma solo per l'istanza corrente di Servlet. Se il server rigenerasse questa istanza allora l'esecuzione del servizio troverebbe condition a true e creerebbe un secondo ExecutorThread.

A conti fatti la questione è un semplicemente di "ambito di vita". Devi far sì che la conzione appartenga ad un ambito superiore a quello di esistenza dell'istanza servlet. Perchè è questo solo il "problema": il ciclo di vita di questi oggetti è determinato esternamente al programma che hai per le mani.

Tutto qua.
Prima di tutto grazie per le informazioni. Ora ti spiego la servlet in questione nel suo metodo init() crea un oggetto ExecuteThread, nel metodo post() io controllo se il suddetto thread, per qualche motivo è terminato (il thread è un loop, non dovrebbe terminare) e in tal caso lo riavvio. Il server non crea una sola istanza di una servlet e vengono generati dei thread che eseguono i metodi post, get, ecc della medesima istanza?
__________________
Il futuro lo conoscerete quando sarà arrivato, prima di allora dimenticatelo.
(Eschilo)
osa è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 19:42   #6
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
Nì. Cioè sì ma bisogna stare attenti a quell'unico.

E' unica nel senso che il server non crea dieci servlet e poi distribuisce alla prima servlet libera il compito di rispondere ad una richiesta.

Cioè non ci sono più servlet che gestiscono contemporaneamente richieste plurime.

Non è unica nel senso di identica. Il server può rimuovere l'istanza che sta usando. Ad esempio dopo un certo periodo in cui non siano arrivate richieste. Quando sarà necessario, il server creerà una nuova istanza della servlet.

Ecco perchè dico, attenzione al campo. Il campo in quanto tale è vincolato all'istanza. Se l'istanza cambia, la nuova avrà il suo nuovo campo, coi suoi diversi valori.

Probabilmente una soluzione sarebbe quella di assicurare la morte del thread nel metodo destroy() della servlet. Ma non sono sicuro perchè le specifiche non sembrano vincolare l'esecuzione del metodo init() di una servlet all'esecuzione del metodo destroy() dell'istanza precedente.

Io ho parlato di esistenza della servlet ma le specifiche parlano di uso dell'istanza della servlet.

Insomma, per farla breve, usa un attributo del contesto. Nel metodo init verifichi se esiste un Esecutore. Se non c'è lo crei e lo avvii. Nel metodo service verifichi se l'esecutore sia ancora attivo. Se non lo è lo rigeneri. E sei in una botte di ferro.
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 19:44   #7
alphacygni
Senior Member
 
L'Avatar di alphacygni
 
Iscritto dal: Mar 2002
Città: Roma - Milano - Lagos
Messaggi: 8579
Quote:
Originariamente inviato da osa Guarda i messaggi
Il server non crea una sola istanza di una servlet e vengono generati dei thread che eseguono i metodi post, get, ecc della medesima istanza?
si, esattamente... infatti se dichiari variabili d'istanza in una servlet hai qualche LEGGERO problema di concorrenza

Pero' non e' detto che l'istanza resti la stessa finche' non "ammazzi" il server...

ma quindi in sostanza a te serve che la servlet ti assicuri di essere "monothread" oppure non ho capito una fava?
__________________
--- --- VENDO AppleCare per Macbook Pro 15"/17" a 200E --- ---
Ho trattato con mezzo forum, per l'altra meta' mi sto attrezzando... tutto ok, tranne con quel diversamente onesto di drwebby
Perditempo di professione: signirr
alphacygni è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 20:34   #8
osa
Senior Member
 
L'Avatar di osa
 
Iscritto dal: Dec 2004
Città: Napoli
Messaggi: 342
Quote:
Originariamente inviato da alphacygni Guarda i messaggi
si, esattamente... infatti se dichiari variabili d'istanza in una servlet hai qualche LEGGERO problema di concorrenza

Pero' non e' detto che l'istanza resti la stessa finche' non "ammazzi" il server...

ma quindi in sostanza a te serve che la servlet ti assicuri di essere "monothread" oppure non ho capito una fava?
Praticamente nella servlet c'è il controllo i mutua esclusione che verifica se ExucuteThread è terminato in tal caso lo riavvia. Ci deve essere solo un thread ExecuteThread in esecuzione. Questo codice mi garantisce ciò?
Codice:
private Object mutex;
private ExecuteThread t;

......

synchronized(mutex){
if ( t.getState().TERMINATE){
Thread t=new ExecuteThred(); //è un thread da me creato
t.start(); 
}
}
__________________
Il futuro lo conoscerete quando sarà arrivato, prima di allora dimenticatelo.
(Eschilo)
osa è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 20:39   #9
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
No. 2, la vendetta.
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 21:01   #10
osa
Senior Member
 
L'Avatar di osa
 
Iscritto dal: Dec 2004
Città: Napoli
Messaggi: 342
Quote:
Originariamente inviato da PGI-Bis Guarda i messaggi
No. 2, la vendetta.
Scusa non avevo letto il post da te scritto.
Se la servlet è rigenerata, l'evantuale thread ExucuteThread in esecuzione non dovrebbe terminare o sbaglio?

Tu mi hai scritto:
Quote:
Insomma, per farla breve, usa un attributo del contesto. Nel metodo init verifichi se esiste un Esecutore. Se non c'è lo crei e lo avvii. Nel metodo service verifichi se l'esecutore sia ancora attivo. Se non lo è lo rigeneri. E sei in una botte di ferro.
Non ho capito come posso verificare, nel metodo init, che l'Esecutore è attivo se uso un attributo di contesto invece di un campo.

Ciao e grazie.
__________________
Il futuro lo conoscerete quando sarà arrivato, prima di allora dimenticatelo.
(Eschilo)

Ultima modifica di osa : 11-07-2007 alle 21:14.
osa è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 21:50   #11
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
Una volta lanciato il Thread fa storia a sè. Con o senza la servlet, quello continua a girare. E, a meno che il gruppo di appartenza non sia particolare, continuerà a farlo finchè la macchina virtuale non sarà ammazzata con un kill. O finchè il suo compito non termini ma questo dipende da cosa c'è nel run e da eventuali invocazioni esplicite del metodo interrupt() se la condizione di interruzione sia gestita nel run().

init.

Nell'init verifichi con:

Codice:
Object o = getServletContext().getAttribute("esecutore");
if(o == null) {
   non c'è: crealo, attivalo e registralo come attributo
} else if(o instanceof ExecutorThread) {
    ExecutorThread t = (ExecutorThread)o;
    if(t non è attivo...) { attivalo }
}
Nel service lo recuperi con lo stesso sistema:

Codice:
Object o = getServletContext().getAttribute("esecutore");
if(o instanceof ExecutorThread) {
    ExecutorThread t = (ExecutorThread)o;
    eccetera
} else {
    grande magagna!
}
E' la stessa cosa che hai già fatto solo che anzichè essere un campo della tua servlet, l'esecutore è un attributo del contesto delle servlet. Siccome il contesto è unico e persistente (rispetto al ciclo di vita di una servlet) l'esecutore, una volta creato, si comporta come un singleton.
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 22:03   #12
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
Ps: se poi anzichè nell'init della servlet crei l'esecutore con un ServletContextListener allora sei proprio EE. Very Java EE .
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 22:05   #13
osa
Senior Member
 
L'Avatar di osa
 
Iscritto dal: Dec 2004
Città: Napoli
Messaggi: 342
Quote:
Originariamente inviato da PGI-Bis Guarda i messaggi
Una volta lanciato il Thread fa storia a sè. Con o senza la servlet, quello continua a girare. E, a meno che il gruppo di appartenza non sia particolare, continuerà a farlo finchè la macchina virtuale non sarà ammazzata con un kill. O finchè il suo compito non termini ma questo dipende da cosa c'è nel run e da eventuali invocazioni esplicite del metodo interrupt() se la condizione di interruzione sia gestita nel run().

init.

Nell'init verifichi con:

Codice:
Object o = getServletContext().getAttribute("esecutore");
if(o == null) {
   non c'è: crealo, attivalo e registralo come attributo
} else if(o instanceof ExecutorThread) {
    ExecutorThread t = (ExecutorThread)o;
    if(t non è attivo...) { attivalo }
}
Nel service lo recuperi con lo stesso sistema:

Codice:
Object o = getServletContext().getAttribute("esecutore");
if(o instanceof ExecutorThread) {
    ExecutorThread t = (ExecutorThread)o;
    eccetera
} else {
    grande magagna!
}
E' la stessa cosa che hai già fatto solo che anzichè essere un campo della tua servlet, l'esecutore è un attributo del contesto delle servlet. Siccome il contesto è unico e persistente (rispetto al ciclo di vita di una servlet) l'esecutore, una volta creato, si comporta come un singleton.
Grazie sei stato di grande aiuto.
__________________
Il futuro lo conoscerete quando sarà arrivato, prima di allora dimenticatelo.
(Eschilo)
osa è offline   Rispondi citando il messaggio o parte di esso
Old 11-07-2007, 23:29   #14
osa
Senior Member
 
L'Avatar di osa
 
Iscritto dal: Dec 2004
Città: Napoli
Messaggi: 342
Perdonami in init() io verifico se esisteva il Thread nel contesto, altrimenti lo setto com this.getServletContext().setAttribute(...) , in questo modo il contesto vive anche se la servlet è rigenerato se ho capito bene o erro?
__________________
Il futuro lo conoscerete quando sarà arrivato, prima di allora dimenticatelo.
(Eschilo)
osa è offline   Rispondi citando il messaggio o parte di esso
Old 12-07-2007, 11:27   #15
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
Sì. Il ciclo di vita del contesto (ServletContext) è più ampio di quello delle servlet. E' legato a quello dell'applicazione web. Parte quando l'applicazione è dispiegata sul web server e termina quando l'applicazione schiatta.
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Google Pixel 10 è compatto e ha uno zoom 5x a 899€: basta per essere un best-buy? Google Pixel 10 è compatto e ha uno zoom ...
Prova GeForce NOW upgrade Blackwell: il cloud gaming cambia per sempre Prova GeForce NOW upgrade Blackwell: il cloud ga...
Ecovacs Deebot X11 Omnicyclone: niente più sacchetto per lo sporco Ecovacs Deebot X11 Omnicyclone: niente più...
Narwal Flow: con il mocio orizzontale lava i pavimenti al meglio Narwal Flow: con il mocio orizzontale lava i pav...
Panasonic 55Z95BEG cala gli assi: pannello Tandem e audio senza compromessi Panasonic 55Z95BEG cala gli assi: pannello Tande...
Amazon fa impazzire i prezzi: ecco i 5 s...
iOS 26 arriva oggi: 8 motivi per aggiorn...
VMSCAPE, nuova variante Spectre: vulnera...
Meta Quest 3 da 512 GB scende ancora: or...
Xiaomi lancia un nuovo e-reader con Andr...
iPhone 16e a meno di 600€ su Amazon: l'a...
NVIDIA arruola Colin King: Intel perde u...
GeForce RTX 6090: Rubin CPX potrebbe ess...
Iliad: si consolida la partnership tecno...
Il SoC a 2 nm di Samsung non sfigura nel...
Prezzo shock per i Galaxy Buds FE + nuov...
Il nuovo SoC di Qualcomm vuole stupire: ...
Offerta lampo per pulire l'auto: aspirap...
I robotaxi di Amazon entrano in azione: ...
ECOVACS DEEBOT T50 PRO OMNI Gen2 domina ...
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: 09:08.


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