1) Can you confirm my definition is right?
Sì. Tre o quattro riferimenti che ho trovato cercando sul web la concomitanza "esclusione reciproca selettiva" sembrano conformi alla tua comprensione: "se un processo compete per le sue risorse contro un sottoinsieme di tutti gli altri processi invece di competere con tutti gli altri processi "
2) In the distributed solution (in which each philosopher competes for both forks against two other philosophers), if instead of 5 philosophers, there were 3 of them, would it still be a SME problem? (I think not, because each philosopher will be competing with all of the others)
Molto probabilmente si tratterà di una PMI o di qualche sapore di area grigia. Pensa alla forchetta che giace tra i filosofi "primo" e "secondo" - il "terzo" filosofo non lo usa e per questo abbiamo "competizione sottoinsieme", limitata solo a primo e secondo
3) And in the centralized "conductor" solution, having 5 philosophers, would it still be a SME problem? (I think it would, because although all processes are competing to get to the waiter, each philosopher is only competing with two of the other to get both specified forks)
Finché definisci i fork come risorse condivise , sarà comunque SME - perché i filosofi "primo" e "terzo" non avranno risorse condivise (forks) per competere.
Però, se definisci il cameriere come una risorsa (in termini di programmazione questo può essere visto come un singleton con accesso conteso - che non sarebbe un progetto troppo grande, credo) - allora ci sarebbe nessuna PMI dal momento che tutti i filosofi competerebbero per l'accesso a quella singola risorsa condivisa.
4) If only 1 reader and 1 writer were allowed, would it still be a SME problem? (I think not, because actually every process will be competing with all the others)
Non sarebbe una PMI perché nel caso come sopra, l'insieme dei processi consiste precisamente di due (lettore e scrittore), ed entrambi hanno bisogno di accesso alle risorse reciprocamente esclusivo: il lettore non può leggere mentre scrittore scritture e scrittore non possono scrivere mentre il lettore legge.
Affinché la PMI si verifichi in lettori e scrittori , dovrebbe esserci 1) più di un lettore - per creare un sottoinsieme che non compete tra sé e 2) almeno uno scrittore - per stabilire un'esigenza di mutua esclusione tra gli accessi in lettura e in scrittura
- La linea di fondo è, per scoprire le PMI, è necessario definire con precisione un insieme di processi e un insieme di risorse. E avere una solida conoscenza di mutex , naturalmente.
Un altro punto da tenere a mente è che lo scopo di questo concetto dall'aspetto sofisticato è piuttosto pratico. Sapere quando alcuni processi non hanno bisogno di competere per una risorsa particolare offre un'opportunità per ridurre la contesa della serratura usando blocchi a grana più fine.
Il problema Readers-writers è un buon esempio qui. Se scopri che ci sono, ad esempio, dieci lettori che si battono pesantemente per avere accesso ad alcune risorse quando non ce n'è bisogno, rivolgendosi a questo potrebbe rendere la tua applicazione su dieci volte più veloce , vai a capire.