Asynchrone Funktionsaufrufe

Stalin

Hallo Leute,

ich bin über solche Funktionen mal bei TAPI 3.0 gestolpert wo man manchen Funktionen als Parameter mitgeben kann, ob diese synchrn oder asynchron durchgeführt werden sollen. Nun ist meine Frage, wie man so einen asynchronen Funktionsaufruf realisieren kann. Threads?? oder gibt es noch andere Möglichkeiten?

Gruß,
Stalin

7H3 N4C3R

Spontan weiß ich nicht, welche Funktionen Du meinst. Ein flüchtiger Blick in die MSDN-Library hat mir zumindest keine Funktionen mit Wahl synchron/asynchron offenbart. Außerdem denke ich, gehört das nach WinAPI

Grundsätzlich muss dort aber doch stehen, wie Du benachrichtigt wirst. Das passiert eigentlich immer nur über eine Message an ein übergebenes Fensterhandle oder über eine Callback-Funktion, die Du übergibst. Wenn dort asynchron steht, solltest Du dich auch darauf einstellen, dass diese asynchron aufgerufen wird. Du solltest an dieser Stelle dann also Synchronisationsmechanismen einsetzen. Ich weiß nicht, ob eine Critical Section ausreichen wird - ich denke nicht, da der Code aus dem Kontext eines anderen Prozesses aufgerufen wird.
Inwiefern hast Du denn überhaupt Erfahrung damit? Einen eigenen Thread wirst Du aber nicht brauchen. Es sei denn, Du willst die synchrone Variante verwenden ^^

Gruß!

net 0

Stalin schrieb:

Nun ist meine Frage, wie man so einen asynchronen Funktionsaufruf realisieren kann. Threads?? oder gibt es noch andere Möglichkeiten?

entweder mit threads oder mit 'zustandsautomaten'. die machen pro aufruf nur einen kleinen teil der gesamtaufgabe. hier mal ein kleines beispiel

#include <stdio.h>

int async_strcpy (char *src, char *dst)
{
    static char *from;
    static char *to;

    if (src && dst)
    {
        from = src;
        to = dst;
    }

    if (*from == 0)
    {
        *to = 0;
        return 1;
    }

    *to++ = *from++;
    return 0;
}

int main()
{
    char *from = "hello, async strcpy";
    char to[256];

    async_strcpy (from, to);
    while (async_strcpy(0,0) == 0)
    {
       // mach was während der string kopiert wird
       putchar('.');
    }
    puts(to);
}

Ponto

Jede Art von nebenläufiger Programmierung kann man dafür verwenden. Threads, Prozesse, beides auch auf anderen Rechnern.

Stalin

Bsp.:

ITBasicCallControl::Connect
The Connect method attempts to complete the connection of an outgoing call.

HRESULT Connect(
  VARIANT_BOOL fSync
);

Parameters
fSync
[in] Boolean indicating whether connection is to be performed synchronously
(VARIANT_TRUE) or asynchronously (VARIANT_FALSE).

Klar die Nachricht, ob das ganze geklappt hat bekomm ich über ein Eventhandler, den ich über einen ConnectPoint (COM) gesetzt habe. Aber wie bekomm ich so was auch hin?
Es geht mir darum, dass ich so eine Konstelation auch bei meiner DLL implementiert habe und nun möchte ich alle angemeldeten Clients mit einem Event beliefern. Aber ich möchte nicht bei jedem Client wartem bis er es abgearbeitet hat, sodnern einfach melden und den nächsten aufrufen. Nun weiß ich aber icht wie ich das am besten machen soll.
Die Clients werden in einer Liste gehalten...

Gruß,
Stalin

Shade Of Mine

das ist etwas anderes.

Es gibt zB gerade bei Sockets natürlich oft asynchrone Sachen (non blocking calls).
Hängt aber von der API ab und intern wird da irgendwo mit Threads gearbeitet werden. Du als Anwender siehst es nur nicht.

Ponto

Shade Of Mine schrieb:

das ist etwas anderes.

Es gibt zB gerade bei Sockets natürlich oft asynchrone Sachen (non blocking calls).
Hängt aber von der API ab und intern wird da irgendwo mit Threads gearbeitet werden. Du als Anwender siehst es nur nicht.

Immer wenn ich asynchron und non-blocking in einem Satz sehe komme ich durcheinander. Asynchrone IO und Non-blocking IO haben nicht viel gemeinsam, außer dass die Systemaufrufe in beiden Fällen nicht blockieren, aber das hast du ja geschrieben.

Ich frage mich aber, ob das tatsächlich durch Threads intern gelöst ist. Das glaube ich eher nicht. Ich glaube das das Interruptgesteuert ist.

Shade Of Mine schrieb:

das ist etwas anderes.

Es gibt zB gerade bei Sockets natürlich oft asynchrone Sachen (non blocking calls).

Hier muss ich Dich aber mal korrigieren. Non-Blocking-Calls sind synchron (einer der großen Irrtümer bei der Socket-Programmierung). Entweder kehrt der Aufruf sofort zurück weil keine Daten da sind, oder er verbringt seine Zeit im Kernel, der die Daten im Buffer bereitstellt. Asynchron wäre es erst, wenn die Funktion sofort zurückkehrt und Du eine Benachrichtigung erhältst (wie auch immer), sobald Dein Buffer gefüllt ist.

net 0

Ponto schrieb:

Ich frage mich aber, ob das tatsächlich durch Threads intern gelöst ist. Das glaube ich eher nicht. Ich glaube das das Interruptgesteuert ist.

beides. das ganze multithreading ist interruptgesteuert. wenn man's genau nimmt, laufen alle windoof-programme in einer interrupt-routine. die 'main-funktion' des kernels (die gibt's tatsächlich). sieht ungefähr so aus:

int main()
{
  hardware_initialisieren();
  scheduler_initialisieren();
  interrupts_einschalten();
  while(1)
  {
     __asm hlt;
  }
}

Ponto

net schrieb:

Ponto schrieb:

Ich frage mich aber, ob das tatsächlich durch Threads intern gelöst ist. Das glaube ich eher nicht. Ich glaube das das Interruptgesteuert ist.

beides. das ganze multithreading ist interruptgesteuert. wenn man's genau nimmt, laufen alle windoof-programme in einer interrupt-routine. die 'main-funktion' des kernels (die gibt's tatsächlich). sieht ungefähr so aus:
int main()
{
  hardware_initialisieren();
  scheduler_initialisieren();
  interrupts_einschalten();
  while(1)
  {
     __asm hlt;
  }
}

Das ist ja ungefähr klar, aber ich meinte, dass für Asynchronous I/O kein neuer Thread gestartet wird. Der Kernel erledigt das nebenbei.

net 0

Ponto schrieb:

Das ist ja ungefähr klar, aber ich meinte, dass für Asynchronous I/O kein neuer Thread gestartet wird. Der Kernel erledigt das nebenbei.

der kernel startet selber threads bzw. hat schon welche laufen für solche zwecke. klar, der user muss selber keine threads starten, dafür hat der kernel ein ganzes arsenal von asynchronen features, apc's, dpc's, system threads, guckst du: http://www.i.u-tokyo.ac.jp/ss/lecture/new-documents/Lectures/03-ThreadScheduling/ThreadScheduling.pdf