Multithreading Frage zur Schnittstelle Main<->Thread

[archon]

Hallo Leute,

ich hab eine Applikation geschieben mit Hilfe von Multithreading.

Der Thread wird von einem Hauptprogramm gestartet. Ab diesen Zeitpunkt arbeitet der Thread und wenn dieser Daten bekommt (über eine serielle schnittstelle) dann schickt er diese Daten über ein Signal, Slot zum Hauptprogramm.

Hier die Frage: Ich hätte lieber nicht das diese Daten über eine Signal, Slot mechanismus gehen...kennt da jemand eine andere Möglichkeit...? ch kann ja nicht einfach return (..) machen)

[Christian81]

Warum nicht über Signal/Slot?
Ein gemeinsamer Speicher geht auch.

[archon]

Warum nicht über Signal/Slot?
Ein gemeinsamer Speicher geht auch.

es werden sehr viele und vorallem kritische Daten auf Bitebene geschickt... Wie sicher ist ein Signal Slot Mechanismus?? Ist es eigentlich der Standardweg bzw. professionelle Weg um eine Kommunikation zwischen Threads aufzubauen??

[Christian81]

Was heist 'wie sicher' ? Ob er bits verliert? Ach ja manchmal kommt mir eins abhanden *lol*
Der normale Weg ist, wie ich schon sagte, über einen gemeinsamen Speicherbereich, falls es sowas wie einen 'normalen' Weg gibt. Ggf. auch über Pipes.

[archon]

Was heist 'wie sicher' ? Ob er bits verliert? Ach ja manchmal kommt mir eins abhanden *lol*
Der normale Weg ist, wie ich schon sagte, über einen gemeinsamen Speicherbereich, falls es sowas wie einen 'normalen' Weg gibt. Ggf. auch über Pipes.

Was meinst du mit gemeinsamen Speicherbereich? Gibts irgendwas über pipes (doku)?

[methusalem]

Moin,

ich mache genau das (serielle Schnittstelle) über den Weg Signal/Slot. Und mir ist bisher noch nicht aufgefallen, das es da zu Problemen kommt.
Ich weiß ja nicht in welcher Geschwindigkeit dein ser. Port die Daten abliefert. Aber ich konnte den Thread künstlich ausbremsen (msleep(100)) und das war immer noch schnell genug.
Wenn du mit gemeinsamen Speicherbereichen arbeitest, musst du auch mit Mutexen oder Semaphoren arbeiten. Bei Signal/Slot - wenn du die Daten als Kopie weitergibst - brauchst du das nicht!

[archon]

(...) mit Mutexen oder Semaphoren arbeiten (...)

irgendwie hab ich das gefühl ich hab keine ahnung von qt...

Gibts da ne doku oder sowas?

[franzf]

(...) mit Mutexen oder Semaphoren arbeiten (...)

irgendwie hab ich das gefühl ich hab keine ahnung von qt...

Gibts da ne doku oder sowas?

Das is nix Qt sondern Threading Doku gibts sicher -> Assistant. Aber auch Online (wenn du willst). Zu Threads im Allgemeinen gibt es sicher genügend Info auf Wikipedia.

Grüße
Franz

[archon]

(...) Das is nix Qt sondern Threading (...)

Ist ja noch schlimmer


najut dann google ich ein wenig

[RHBaum]

Der Signal/Slot Weg ist halt immer die QT Variante

Die muss man nicht nehmen, aber man kann.

Performancetechnisch iss sie eher kritisch ... weil der Signal/slot mechanismuss verzoegert wird, also man temporaer daten speichert, mit queues arbeitet etc. und nicht nur eine kopie der daten gezogen wird.
Dafuer isses halt komfortabel.

Eine (von vielen programmiererregeln) sagt, erstmal die funktionalitaet implementieren, und dann optimieren.
Also zuerst mit Signals und Slots bauen, wenn nicht von Haus aus was dagegen spricht (bei ner seriellen schnittstelle hasst sicher viel luft auf der performance-seite). Und erst wenn es zu engpaessen kommt, optimieren, bzw. alternative moeglichkeiten suchen.
Sonst wird man nie fertig.

Ciao ...

[archon]

(...)
Eine (von vielen programmiererregeln) sagt, erstmal die funktionalitaet implementieren, und dann optimieren.

Hab immer daran gelaubt es gibt leute die es sofort optimal programmieren... Ne aber echt das mit den Signalen bzw. Slots denk ich auch mal ist nicht der weisheit letzten schluss. Mal sehen...

gruss + danke

[unbekannt]

...

[Christian81]

In Qt4.4 ist QSharedMemory mit dabei.