AIO sur OSX: est-il implémenté dans le noyau ou avec des threads utilisateur? Autres options?

Question

Je travaille sur mon petit framework C ++ et j'ai une classe de fichiers qui devrait également prendre en charge la lecture et l'écriture asynchrones. La seule solution autre que l'utilisation d'E / S de fichiers synchrones dans certains threads de travail que j'ai trouvés est AIO. Quoi qu'il en soit, je regardais autour de moi et lisais quelque part, qu'en Linux, AIO n'est même pas implémenté dans le noyau mais plutôt avec les threads utilisateur. Est-ce que la même chose est vraie pour OSX? Une autre préoccupation est la fonctionnalité des rappels d'Aio qui doit engendrer un fil supplémentaire pour chaque rappel car vous ne pouvez pas affecter un certain fil ou un threadpool pour en prendre soin (les signaux ne sont pas une option pour moi). Voici donc les questions résultant de cela:

• L'AIO est-elle mise en œuvre dans le noyau d'Osx et est donc très probablement meilleure que ma propre implémentation threadée?

• Le système de rappel - peut-il faire un fil pour chaque rappel - devenir un goulot d'étranglement en pratique?

• Si AIO ne vaut pas la peine d'être utilisé sur OSX, y a-t-il d'autres alternatives sur UNIX? à Cocoa? en carbone?

• Ou devrais-je simplement imiter les E / S asynchrones avec mon propre threadpool?

Quelle est votre expérience sur le sujet?

Answer 1

Vous pouvez voir exactement comment AIO est implémenté sur OSX à droite ici.

L'implémentation utilise des threads de noyau, une file d'attente de travaux que chaque fil apparaît et exécute de manière bloquante dans une file d'attente de priorité en fonction de la priorité de chaque demande (au moins c'est à quoi il ressemble à un premier coup d'œil).

Vous pouvez configurer le nombre de threads et la taille de la file d'attente avec sysctl. Pour voir ces options et les valeurs par défaut, exécutez sysctl -a | grep aio

kern.aiomax = 90
kern.aioprocmax = 16
kern.aiothreads = 4

D'après mon expérience, pour qu'il soit logique d'utiliser AIO, ces limites doivent être beaucoup plus élevées.

Quant aux rappels dans les threads, je ne crois pas que Mac OS X le prend en charge. Il ne fait que des notifications de complétion via des signaux (voir source).

Vous pourriez probablement faire un bon travail dans votre propre pool de fil. Une chose que vous pourriez faire mieux que la mise en œuvre actuelle de Darwin est de trier vos travaux de lecture par emplacement physique sur le disque (voir fcntl et F_LOG2PHYS) qui pourrait même vous donner un avantage.

Answer 2

@Moka: Désolé de dire que vous vous trompez sur l'implémentation Linux, à partir du noyau 2.6, il y a une implémentation du noyau de l'AIO, qui vient dans Libaio (Libaio.h)

L'implémentation qui n'utilise pas de threads de noyau mais qui utilise à la place les threads utilisateur est POSIX.1 AIO, et il le fait de cette façon pour le rendre plus portable, car tous les événements d'achèvement du système d'exploitation basés sur UNIX ne prennent pas les événements du noyau.