Quali sono i vantaggi della coda POSIX o della normale coda della struttura dati?

Question

Quali sono i vantaggi della coda POSIX o della normale coda della struttura dati?

#1 da (3 voti)

1

Sto programmando con il dispositivo incorporato su cui gira Linux, dove la memoria è inferiore, ho solo 64 MB di flash. Ho pianificato di utilizzare le code per la comunicazione del thread.

In cui mi sono imbattuto nella coda POSIX o nella semplice coda.

In realtà, il mio bisogno è che io non voglia che la coda sia priorizzata. Voglio sapere i pro e i contro della coda POSIX, quindi avrò una buona immagine

Mi chiedo quale sia il modo migliore ottimizzato usando POSIX queue o semplicemente una semplice coda alla mia situazione?

Il primo thread fa HTTP POST e il secondo thread fa HTTP GET . Questi due thread devono comunicare quando i dati sono scritti o ricevuti.

Ho letto che la coda POSIX utilizza il kernel Linux, in quel caso, ha un sovraccarico maggiore rispetto all'utilizzo della propria coda di strutture dati?

In altre parole, IPC leggero, qualcosa come pipe unidirezionali per la comunicazione dei thread invece della coda POSIX, ma non conosciamo il vero vantaggio della coda POSIX.

EDIT: ho solo 512 MB di RAM nel mio dispositivo incorporato.

c linux data-structures message-queue posix

posta danglingpointer 19.06.2017 - 14:08

fonte

1 risposta

Leggi altre domande sui tag c linux data-structures message-queue posix

Che tipo di bug puntatore è questo in particolare? Come automatizzare la generazione di ID?

score 3 · Answer 1

Una coda POSIX (vedi mq_overview (7) ) è per inter-process comunicazione (quindi è piuttosto costosa, ma potrebbe essere utilizzata per la comunicazione tra thread). È possibile utilizzare una struttura dati di coda protetta da ad es. un mutex POSIX. Speriamo (grazie a futex (7) probabilmente usato da pthreads(7) ) non è necessario un cambio di contesto per il kernel nei casi comuni in cui non è necessario il blocco .

I'm programming with the embedded device running Linux, where memory is less, I just have 64MB flash only.

AFAIK il dispositivo flash è più un disco -i.e. un dispositivo a blocchi- di una memoria. Le code o pipe POSIX consumano RAM (in realtà spazio di indirizzamento virtuale e spazio di memoria del kernel), non flash.

Se hai già un loop di eventi (ad esempio intorno a sondaggio (2) o il vecchio select (2) ...) potresti impostare un pipe (7) a self al momento dell'inizializzazione (e ha un thread che scrive la pipe, e un'altra lettura esso).

First thread does HTTP POST and Second thread does HTTP GET.

Hai preso in considerazione l'utilizzo di qualche libreria client HTTP come libcurl (forse usando la sua modalità multi )? Potrebbe essere utile (e potresti evitare il multi-threading se pensi in stile di passaggio continuo ).

I'm wondering what's the best-optimised way using POSIX queue or just simple queue to my situation?

Per gli scopi sincronizzazione (in un approccio multi-threading) la "coda semplice" ha bisogno, ad es. alcuni mutex (per bloccare e serializzare l'accesso, evitando così che entrambi i thread lo modifichino simultaneamente, il kernel è ancora coinvolto nei futex in conflitto). Non so cosa sia più veloce (non sono sicuro che sia importante ma preferirei mutex e multi-threading), e hai bisogno di un benchmark se ti interessa davvero.

BTW, multi-threading (e anche multi-processing) consuma memoria (dato che ogni thread probabilmente richiede almeno un megabyte per il suo stack di chiamate ).