pthread win32
1.0.0
Kombinierter pthread-win32 -Fork von RedFox20 + Oktonion + WinBuild
PThread https://github.com/WinBuilds/pthread-win32 ändert sich:
Dies ist ein Fork der Version 2.10.0.0 des pthreads-win32-Pakets. Der ABI dieser Gabel unterscheidet sich vom Original.
Durchgeführte Änderungen:
Der Typ des Wiederverwendungszählers in ptw32_handle_t wurde von int in size_t geändert, um Server mit langer Laufzeit zu unterstützen.
Nicht verwendete Elemente aus pthread_once_t entfernt
Diese Bibliothek wird häufig mit unseren anderen Visual Studio 2022-Projekten getestet.
Im Allgemeinen verwende (und habe) ich für meine Arbeit die MSVC20xx-Projektdateien verwendet. Die Makefiles wurden viel seltener verwendet und sind möglicherweise veraltet.
Bitte beachten Sie die Commit-Nachricht d4b0ef6b: Während das MSVC2022/2019-Projekt durchgehend so konfiguriert wurde, dass es meinen internen Einstellungen entspricht, passt es möglicherweise nicht zu Ihren.
Sie können die Einstellungen natürlich jederzeit manuell bearbeiten, aber wenn Sie dies für viele vcxproj -Projektdateien tun müssen, ist möglicherweise die Erstellung eines Skripts für die Aufgabe die richtige Lösung. Beispielskripte, die so etwas tun, finden Sie update-vcxproj.js und patch-vcxproj.js . Ich verwende diese, um sicherzustellen, dass alle meine C/C++-Projekte genau die gleichen Build-Einstellungen haben, damit ich keine bösen Laufzeitüberraschungen erlebe, weil einige Projekte beschlossen haben, mit ganz leicht unterschiedlichen Debug-/Release-Static-/DLL-Laufzeitbibliotheken zu erstellen. usw. usw.: die unzähligen Möglichkeiten, die Sie bekommen können?? durch Ihr Build-System in einer Windows-Umgebung. Spaß! ?
(17.12.2021)
Dies ist eine Mikroversion mit hauptsächlich administrativen Korrekturen.
mkdir b && cd b && cmake -G "Visual Studio 16 2019" .. : OK. Das bedeutet, dass mehrere lauernde Fehler behoben wurden und wir einen Workaround für den CMake-Mist (das Tool gefällt mir immer noch nicht) eingefügt haben, wenn C-Quellen bedingt als C++ kompiliert werden sollen (siehe auch pthread-EH.cpp). und pthread-JMP.c: zwei neue Wrapper-Quelldateien). Dies ist eine Mikroversion mit hauptsächlich administrativen Korrekturen.
Die MSVC- und MinGW64-Builds wurden auf der SMP-Architektur (Intel x64 Hex Core) getestet, indem die mitgelieferte Testsuite sowie die Stress- und Benchmark-Tests abgeschlossen wurden.
Stellen Sie sicher, dass Sie Ihre Builds mit der Testsuite ausführen. Wenn Sie Fehler feststellen, überlegen Sie bitte, wie Ihre Toolchains möglicherweise zu dem Fehler beitragen. Ausführlichere Beschreibungen der Toolchains und Testsysteme, die wir verwendet haben, um die Tests erfolgreich zu bestehen, finden Sie in der README-Datei.
Wir empfehlen MinGW64 gegenüber MinGW nur für 64- und 32-Bit-GNU-CC-Builds, da die MinGW-DWARF2-Ausnahmebehandlung bei C++-Builds einige Probleme beim Thread-Abbruch verursacht.
MinGW64 enthält auch eine eigene native Pthreads-Implementierung, die Sie möglicherweise lieber verwenden möchten. Wenn Sie unsere Bibliothek erstellen möchten, müssen Sie bei der Installation die Option „Native Win32-Threads“ auswählen. Wir empfehlen, auch die SJLJ-Ausnahmebehandlungsmethode für MinGW64-w32-Builds auszuwählen. Für MinGW64-w64-Builds sollte entweder die SJLJ- oder SEH-Ausnahmebehandlungsmethode funktionieren.
(08.08.2018)
Beachten Sie, dass es sich hierbei um eine neue Hauptversion handelt. Das Hauptversionsinkrement führt zwei ABI-Änderungen zusammen mit anderen Namensänderungen ein, die eine Neukompilierung der verknüpfenden Anwendungen und möglicherweise einige Textänderungen an Makroreferenzen zur Kompilierungszeit in Konfigurations- und Quelldateien erfordern, z. B. PTW32_*-Änderungen in PTW32_ , ptw32_ in ptw32_* usw .
Mit Zustimmung aller wesentlichen relevanten Mitwirkenden wird pthreads-win32 / pthreads4w Version 3, mit Ausnahme von vier Dateien, unter den Bedingungen der Apache-Lizenz v2.0 veröffentlicht. Die APLv2 ist mit den GPLv3- und LGPLv3-Lizenzen kompatibel und daher darf dieser Code weiterhin legal in GPLv3- und LGPLv3-Projekten enthalten sein.
Als wesentlicher relevanter Mitwirkender wurde jemand definiert, der Originalcode beigesteuert hat, der eine Funktion implementiert, die in künftigen Versionen vorhanden ist. Davon ausgeschlossen sind mehrere Mitwirkende, die veralteten Code beigesteuert oder Patches bereitgestellt haben, die Fehler beheben, Code aus ästhetischen oder praktischen Gründen neu organisieren oder Build-Prozesse verbessern. Diese Unterscheidung war notwendig, um voranzukommen, da wahrscheinlich nicht alle Mitwirkenden erreichbar sein würden. Alle Mitwirkenden sind in der Datei MITARBEITER aufgeführt.
Die vier Dateien, die LGPL bleiben, aber auf v3 geändert werden, sind Dateien, die zum Konfigurieren der GNU-Umgebungs-Builds verwendet werden:
aclocal.m4
configure.ac
GNUmakefile.in
tests/GNUmakefile.in
Zu den Mitwirkenden, die diese Änderung entweder beantragt oder ihr bei Rücksprache zugestimmt haben, gehören:
pthreads-win32 / pthreads4w Version 2-Versionen bleiben LGPL, aber Version 2.11 und höher werden unter Version 3 dieser Lizenz veröffentlicht, sodass alle Ergänzungen zum pthreads4w Version 3-Code, der auf Version 2 zurückportiert wird, diesen Code nicht verunreinigen.
Einige Änderungen ab dem 26.02.2011 sind möglicherweise nicht mit Systemen vor Windows 2000 kompatibel.
Neue Fehlerbehebungen in allen Versionen seit 2.8.0 wurden NICHT auf die 1.xx-Serie angewendet.
Die MSVC-, MinGW- und MinGW64-Builds wurden auf der SMP-Architektur (Intel x64 Hex Core) getestet, indem die mitgelieferte Testsuite sowie die Stress- und Benchmark-Tests abgeschlossen wurden.
Stellen Sie sicher, dass Sie Ihre Builds mit der Testsuite ausführen. Wenn Sie Fehler feststellen, überlegen Sie bitte, wie Ihre Toolchains möglicherweise zu dem Fehler beitragen. Ausführlichere Beschreibungen der Toolchains und Testsysteme, die wir verwendet haben, um die Tests erfolgreich zu bestehen, finden Sie in der README-Datei.
Wir empfehlen MinGW64 gegenüber MinGW nur für 64- und 32-Bit-GNU-CC-Builds, da die MinGW-DWARF2-Ausnahmebehandlung bei C++-Builds einige Probleme beim Thread-Abbruch verursacht.
MinGW64 enthält auch eine eigene native Pthreads-Implementierung, die Sie möglicherweise lieber verwenden möchten. Wenn Sie unsere Bibliothek erstellen möchten, müssen Sie bei der Installation die Option „Native Win32-Threads“ auswählen. Wir empfehlen, auch die SJLJ-Ausnahmebehandlungsmethode für MinGW64-w32-Builds auszuwählen. Für MinGW64-w64-Builds sollte entweder die SJLJ- oder SEH-Ausnahmebehandlungsmethode funktionieren.
Abgesehen von den folgenden Funktionen entspricht diese Version der Version 2.11.0.
Diese Version führt eine Änderung an pthread_t und pthread_once_t ein, die sich auf Anwendungen auswirkt, die mit der Bibliothek verknüpft sind.
pthread_t: bleibt eine Struktur, erweitert jedoch den Wiederverwendungszähler von 32 Bit auf 64 Bit. Auf 64-Bit-Rechnern erhöht sich die Gesamtgröße des Objekts nicht. Wir nutzen einfach 4 Bytes Auffüllung, um das Risiko zu verringern, dass der Zähler in sehr lang laufenden Anwendungen von klein auf praktisch Null springt. Der 64-Bit-Wiederverwendungszähler verlängert die risikofreie Laufzeit von Monaten (bei einer durchschnittlichen Thread-Lebensdauer von 1 ms) auf Jahrhunderte (bei einer durchschnittlichen Thread-Lebensdauer von 1 ns).
pthread_once_t: Entfernt zwei längst veraltete Elemente und reduziert ihre Größe.
(08.08.2018)
Neue Fehlerbehebungen in allen Versionen seit 2.8.0 wurden NICHT auf die 1.xx-Serie angewendet.
Einige Änderungen ab dem 26.02.2011 sind möglicherweise nicht mit Systemen vor Windows 2000 kompatibel.
pthreads-win32 / pthreads4w Version 2.11 und alle zukünftigen 2.x-Versionen werden unter der Lesser GNU Public License Version 3 (LGPLv3) veröffentlicht.
Die nächste Hauptversion dieser Software (Version 3) wird unter der Apache-Lizenz Version 2.0 (ALv2) veröffentlicht. Durch die Veröffentlichung von 2.11 unter LGPLv3 können Änderungen an Version 3 dieser Software künftig auf Version 2 zurückportiert werden. Darüber hinaus können alle GPL-Projekte, die diese Bibliothek derzeit verwenden, weiterhin entweder Version 2 oder 3 dieses Codes in ihren Projekten verwenden.
Weitere Informationen finden Sie unter: https://www.apache.org/licenses/GPL-compatibility.html
Um mit dieser Änderung konsistent zu bleiben, werden ab diesem Zeitpunkt Änderungen an dieser Bibliothek nur noch gegenüber Version 3 dieser Software gemäß den Bedingungen von ALv2 akzeptiert. Anschließend werden sie ggf. auf Version 2 zurückportiert.
Wir hoffen, Version 3 gleichzeitig mit Version 2.11 veröffentlichen zu können.
Diese Version wurde auf der SMP-Architektur (Intel x64 Hex Core) getestet, indem die mitgelieferte Testsuite sowie die Stress- und Benchmark-Tests abgeschlossen wurden.
Stellen Sie sicher, dass Sie Ihre Builds mit der Testsuite ausführen. Wenn Sie Fehler feststellen, überlegen Sie bitte, wie Ihre Toolchains möglicherweise zu dem Fehler beitragen. Ausführlichere Beschreibungen der Toolchains und Testsysteme, die wir verwendet haben, um die Tests erfolgreich zu bestehen, finden Sie in der README-Datei. Wir empfehlen MinGW64 gegenüber MinGW32 sowohl für 64- als auch 32-Bit-GNU-CC-Builds. MinGW64 enthält auch eine eigene unabhängige pthreads-Implementierung, die Sie möglicherweise lieber verwenden möchten.
Für Microsoft-Toolchain-Builds: (1) Für die statische Verknüpfung müssen sowohl diese Bibliothek als auch alle verknüpften Bibliotheken oder Anwendungen konsistent mit /MT kompiliert werden.
(2) Statische Bibliotheken wurden in libpthreadV*.lib umbenannt, um sie von den DLL-Importbibliotheken pthreadV*.lib zu unterscheiden.
(3) Wenn Sie eine gemischte Verknüpfung verwenden, z. B. die Verknüpfung der statischen /MT-Version der Bibliothek mit einer mit /MD verknüpften Anwendung, können Sie möglicherweise GetLastError() verwenden, um den Fehlercode abzufragen, da die Bibliothek sowohl errno (über _set_errno ()) und SetLastError().
Entfernen Sie den Versuch, PTW32_USES_SEPARATE_CRT in den Headern festzulegen, was zu unerwarteten Ergebnissen führen kann. In bestimmten Situationen möchte ein Benutzer es möglicherweise explizit in seiner Umgebung definieren, um seine Auswirkungen aufzurufen, entweder beim Erstellen der Bibliothek oder einer Anwendung oder bei beiden. Siehe README.NONPORTABLE. – Ross Johnson
Die Bibliothek sollte in vollständig statisch verknüpften Szenarien zuverlässiger sein. Hinweis: Wir haben den PIMAGE_TLS_CALLBACK-Code entfernt und auf die frühere Methode zurückgegriffen, die in allen Compiler-Editionen zuverlässiger zu sein scheint.
Verschiedene Korrekturen an GNUmakefile. Obwohl diese Datei entfernt wurde, wurden die Änderungen der Vollständigkeit halber als Commits im Repository aufgezeichnet.
MinGW64-w64 definiert pid_t als __int64. sched.h spiegelt dies nun wider.
Es wurden mehrere Tests behoben, die auf Maschinen unter Last fehlschlugen. Bei anderen Tests, die ähnliche grobe Mechanismen zum Synchronisieren von Threads verwendeten (Einheitstests), wurden dieselben Verbesserungen vorgenommen: semaphore5.c erkennt, dass sem_destroy legitimerweise EBUSY zurückgeben kann; mutex6*.c, mutex7*.c und mutex8*.c ersetzten alle ein einzelnes Sleep() durch eine Abfrageschleife.
(18.09.2016)
Neue Fehlerbehebungen in allen Versionen seit 2.8.0 wurden NICHT auf die 1.xx-Serie angewendet.
Einige Änderungen ab dem 26.02.2011 sind möglicherweise nicht mit Systemen vor Windows 2000 kompatibel.
Diese Version wurde auf der SMP-Architektur (Intel x64 Hex Core) getestet, indem die mitgelieferte Testsuite sowie die Stress- und Benchmark-Tests abgeschlossen wurden.
Stellen Sie sicher, dass Sie Ihre Builds mit der Testsuite ausführen. Wenn Sie Fehler feststellen, überlegen Sie bitte, wie Ihre Toolchains möglicherweise zu dem Fehler beitragen. Ausführlichere Beschreibungen der Toolchains und Testsysteme, die wir verwendet haben, um die Tests erfolgreich zu bestehen, finden Sie in der README-Datei. Wir empfehlen MinGW64 gegenüber MinGW32 sowohl für 64- als auch 32-Bit-GNU-CC-Builds. MinGW64 enthält auch eine eigene unabhängige pthreads-Implementierung, die Sie möglicherweise lieber verwenden möchten.
Neue Routinen: pthread_timedjoin_np() pthread_tryjoin_np()
sched_getaffinity() sched_setaffinity() pthread_getaffinity_np() pthread_setaffinity_np() pthread_attr_getaffinity_np() pthread_attr_setaffinity_np()
pthread_getname_np() pthread_setname_np() pthread_attr_getname_np() pthread_attr_setname_np()
pthread_win32_getabstime_np()
GNU-Compilerumgebungen (MinGW32 und MinGW64) haben jetzt die Möglichkeit, Autoconf zu verwenden, um den Build automatisch zu konfigurieren.
Builds: Neue Makefile-Ziele wurden hinzugefügt und vorhandene Ziele geändert oder entfernt. Ziele sind beispielsweise das Erstellen und Testen aller möglichen Konfigurationen von DLLs und statischen Bibliotheken.
GNU-Compiler-Builds nutzen jetzt explizit die Kompatibilität mit den Standards ISO C und C++ 2011. Wenn Ihr GNU-Compiler dies nicht unterstützt, ziehen Sie bitte eine Aktualisierung in Betracht. Die automatische Konfiguration ist jetzt über das Skript „configure“ möglich. Das Skript muss mit autoconf generiert werden – siehe README-Datei. Vielen Dank an Keith Marshall vom MinGW-Projekt.
Statische Verknüpfung: Die autostatische Funktionalität wurde nach dll.c verschoben und erweitert, sodass Builds, die MSVC8 und höher verwenden, nicht mehr erfordern, dass Apps pthread_win32_thread_detach_np() aufrufen. Das heißt, die gesamte DllMain-Funktionalität ist jetzt automatisch für die statische Verknüpfung dieser Builds verfügbar.
Einige statische nmake-Verknüpfungsziele wurden deaktiviert: Aufgrund eines Problems mit dem TLS-Verhalten wurden die V*-small-static* nmake-Ziele in Makefile deaktiviert. Das Problem wird durch Tests/semaphore3.c aufgedeckt, wo der Aufruf pthread_self() innerhalb des Threads nicht das richtige POSIX-Thread-Handle zurückgibt, sondern stattdessen ein neues „implizites“ POSIX-Thread-Handle zurückgibt. Implizite Pthread-Handles haben den Status „Getrennter Thread“, was dazu führt, dass der Aufruf von pthread_detach() innerhalb des Threads EINVAL zurückgibt. Die V*-statischen* Ziele scheinen nicht betroffen zu sein. Der Hauptunterschied besteht darin, dass letztere aus einer einzigen Kompilierungseinheit generiert werden.
Die statische Verknüpfung kleiner Objektdateien funktioniert jetzt (MinGW). Der autostatische Code ist erforderlich, aber nichts verweist explizit auf diesen Code und wurde daher optimiert.
sem_getvalue() könnte den errno-Wert zurückgeben, anstatt errno zu setzen und -1 zurückzugeben.
Errno-Werte gingen verloren, wenn die Bibliothek statisch mit der Laufzeitbibliothek verknüpft war, was auch bedeutete, dass die Anwendung eine separate Laufzeitinstanz verwendete. Dies ist immer noch der Fall, mit der Ausnahme, dass ein Build-Schalter hinzugefügt wurde, der die Integration eines robusteren Fehlerstatus ermöglicht, d. h. das Abrufen des Rückkehrcodes über GetLastError() ermöglicht.
Identifizierte die Ursache für erhebliche Fehler im Zusammenhang mit Abbruch und pthread_exit() für die GCE-Build-Konfiguration (GNU C++), die von Mingw32 stammt. Ich bin mir nicht sicher, ob dies allgemein gilt oder nur beim Erstellen von 32-Bit-Bibliotheken und Apps, die auf 64-Bit-Systemen ausgeführt werden. Diese Fehler treten nicht auf, wenn Mingw64-32-Bit-Builds (GCC mit aktivierter Multilib erstellt) auf 64-Bit-Systemen ausgeführt werden.
Der in Version 2.9.x eingeführte Fehler pthread_key_delete() führte dazu, dass diese Routine auf eine Weise fehlschlug, die von der Testsuite nicht erkannt wurde. Es wurde ein neuer Test hinzugefügt, um zu bestätigen, dass sich diese Routine korrekt verhält, insbesondere wenn Schlüssel mit Destruktoren gelöscht werden, bevor Threads beendet werden.
pthread_win32_process_attach_np() behebt potenzielle Fehler/Sicherheit beim Suchen und Laden von QUSEREX.DLL.
_POSIX_THREAD_ATTR_STACKADDR ist jetzt in pthread.h auf -1 gesetzt. Als Konsequenz gibt pthread_attr_setstackaddr() nun ENOSYS zurück. Zuvor wurde der Wert gespeichert und konnte abgerufen werden, wurde aber ansonsten nicht verwendet. pthread_attr_getstackaddr() gibt ENOSYS entsprechend zurück.
Ein potenzieller Speicherverlust in pthread_mutex_init() wurde behoben. Das Leck würde nur auftreten, wenn die Mutex-Initialisierung fehlschlägt (äußerst selten, wenn überhaupt).
Es wurden Zeitüberschreitungen von weniger als einer Millisekunde behoben, die dazu führten, dass die Bibliothek ausgelastet war.
Beheben Sie eine Race-Bedingung und einen Absturz in MCS-Sperren. Der Code für die Verwaltung der Warteschleife in ptw32_mcs_lock_acquire lief mit dem Code für die Warteschlangenverwaltung in ptw32_mcs_lock_release in Konflikt und verursachte einen Segmentierungsfehler.
(27.05.2012)
Neue Fehlerbehebungen in dieser Version seit 2.8.0 wurden NICHT auf die 1.xx-Serie angewendet.
Diese Version ersetzt eine äußerst kurze Version 2.9.0 und fügt einige in letzter Minute vorgenommene Nicht-Code-Änderungen hinzu, um besser beschreibende Eigenschaften in die DLLs einzubetten, um die Zielarchitektur und Build-Umgebungen anzuzeigen.
Einige Änderungen nach dem 26.02.2011 in CVS sind möglicherweise nicht mit Systemen vor Windows 2000 kompatibel.
Von der Verwendung einer anderen als der „C“-Version der Bibliothek wird jetzt abgeraten. Das heißt, die „C++“-Version besteht einige Tests nicht und bietet keine zusätzliche Funktionalität.
Diese Version wurde auf der SMP-Architektur (Intel x64 Hex Core) getestet, indem die enthaltene Testsuite sowie Stress- und Benchmark-Tests abgeschlossen wurden.
Die DLL-Eigenschaften enthalten jetzt ordnungsgemäß die Zielarchitektur, dh wenn Sie im Explorer mit der rechten Maustaste auf die Datei pthreadVC2.dll klicken und die Registerkarte „Details“ auswählen, werden der Compiler und die Architektur im Beschreibungsfeld angezeigt, z. B. „MS C x64“ oder „MS C x86“.
Die Abhängigkeit von der Winsock-Bibliothek ist jetzt über #define RETAIN_WSALASTERROR in config.h frei wählbar. Es ist standardmäßig undefiniert, es sei denn, WINCE ist definiert (da ich (RJ) mir der dortigen Abhängigkeit nicht sicher bin).
(MSC- und GNU-Builds) Die statisch verknüpfte Bibliothek initialisiert und bereinigt jetzt automatisch beim Start/Beenden des Programms, dh statisch verknüpfte Anwendungen müssen die Routinen pthread_win32_process_attach_np() und pthread_win32_process_detach_np() nicht explizit aufrufen. Die pro-Thread-Routine pthread_win32_thread_detach_np() wird auch beim Beenden des Programms aufgerufen, um vom primären Windows-nativen Thread erfasste POSIX-Ressourcen zu bereinigen, wenn ich (RJ) den Prozess richtig verstehe. Andere native Windows-Threads, die POSIX-API-Routinen aufrufen, müssen möglicherweise die Thread-Trennroutine beim Thread-Beenden aufrufen, wenn die Anwendung auf zurückgewonnene POSIX-Ressourcen oder die Ausführung von POSIX TSD (TLS)-Destruktoren angewiesen ist. Beschreibungen dieser Routinen finden Sie in README.NONPORTABLE.
Robuste Mutexe werden im PROCESS_PRIVATE-Bereich implementiert. Beachten Sie, dass pthread_mutex_*-Funktionen möglicherweise andere Fehlercodes für robuste Mutexe zurückgeben, als sie es sonst bei normaler Verwendung tun. Beispielsweise ist pthread_mutex_unlock erforderlich, um den Besitz für alle Mutex-Typen zu überprüfen, wenn der Mutex robust ist, während dies bei den „normalen“ nicht-mutexen nicht der Fall ist. Robuster Mutex-Typ.
pthread_getunique_np wird aus Gründen der Kompatibilität auf Quellebene mit einigen anderen Implementierungen implementiert. Diese Routine gibt eine 64-Bit-Sequenznummer zurück, die eindeutig einem Thread zugeordnet ist. Es kann von Anwendungen verwendet werden, um POSIX-Thread-Handles zu bestellen oder zu hashen.
Viele weitere Änderungen für 64-Bit-Systeme.
Verschiedene Modifikationen und Korrekturen zum Erstellen und Testen für WinCE.
Fix pthread_cond_destroy() – sollte kein Abbruchpunkt sein. Andere kleinere Build-Probleme behoben.
Entfernen Sie eine potenzielle Deadlock-Bedingung aus pthread_cond_destroy().
Verschiedene Modifikationen zum Erstellen und Testen für Win64.
Verschiedene Korrekturen an der QueueUserAPCEx-Async-Cancel-Helper-DLL (dies ist ein separater Download) und Pthreads-Codebereinigungen.
Mögliche NULL-Zeiger-Referenz entfernt.
Die Anforderung, dass Anwendungen die Anzahl der Threads, die pthread_barrier_wait aufrufen, nur auf die Barrierenanzahl beschränken müssen, wurde entfernt. Außerdem wurde der Konflikt zwischen barrier_wait und barrier_destroy reduziert. Diese Änderung wird die Barrieren etwas verlangsamt haben, halbiert jedoch die Anzahl der pro Barriere verbrauchten Semaphoren auf eins.
Ein Handle-Leck in sched_[gs]etscheduler wurde behoben.
Alle POSIX-Makros für die Wiedereinstiegsfunktionskompatibilität wurden aus pthread.h entfernt. Einige waren einfach semantisch nicht korrekt.
Threads versuchen nicht mehr, nicht abgefangene Ausnahmen außerhalb des Thread-Bereichs zu übergeben (nur C++- und SEH-Builds). Nicht abgefangene Ausnahmen führen nun dazu, dass der Thread mit dem Rückkehrcode PTHREAD_CANCELED beendet wird.
Viele Casting-Korrekturen, insbesondere für x64, Interlocked-Korrekturen und Überarbeitungen für x64.
Die Abhängigkeit von der Winsock-Bibliothek ist jetzt über #define RETAIN_WSALASTERROR in config.h frei wählbar. Es ist standardmäßig undefiniert, es sei denn, WINCE ist definiert (da RJ sich der dortigen Abhängigkeit nicht sicher ist).
Mehrere statische POSIX-Mutexe, die für die interne Verwaltung verwendet werden, wurden durch MCS-Warteschlangensperren ersetzt, um den Ressourcenverbrauch, insbesondere die Verwendung von Win32-Objekten, zu reduzieren.
Aus Sicherheitsgründen muss die QuserEx.dll, falls verwendet, jetzt im Windows-Systemordner installiert werden.
robust[1-5].c – Robuste Mutexe sequence1.c – pro Thread eindeutige Sequenznummern
Alle mutex*.c-Tests wurden, soweit angemessen, geändert, um auch robuste Mutexe unter den gleichen Bedingungen zu testen. Wo immer möglich, wurden robuste Mutex-Benchtests zu benchtest*.c hinzugefügt.
(22.12.2006)
Neue Fehlerbehebungen in dieser Version seit 2.7.0 wurden nicht auf die Version 1.xx-Serie angewendet. Es ist wahrscheinlich an der Zeit, Version 1 fallen zu lassen.
Diese Version wurde noch nicht auf SMP-Architekturen getestet. Alle Tests bestehen auf einem Einprozessorsystem.
Sem_destroy konnte EBUSY zurückgeben, obwohl keine Threads auf dem Semaphor warteten. Andere Rennen rund um die (interne) Ungültigmachung von Semaphorstrukturen wurden ebenfalls entfernt.
semaphore5.c – testet die oben genannte Fehlerbehebung.
(04.06.2005)
Alle neuen Funktionen in dieser Version wurden in Version 1.11.0 zurückportiert, einschließlich der Integration von MCS-Sperren in pthread_once. Die Versionen 1 und 2 bleiben jedoch inkompatibel, obwohl sie jetzt in Leistung und Funktionalität identisch sind.
Diese Version wurde sowohl auf Einprozessor- als auch auf Mehrprozessorsystemen getestet (die Testsuite bestanden).
Pthread_once wurde neu implementiert, um die Prioritätserhöhung und andere Komplexität zu entfernen und die Robustheit zu verbessern. Rennen für Win32-Handles, die nicht recycle-eindeutig sind, wurden entfernt. Die allgemeine Form von pthread_once ist jetzt dieselbe wie die zuvor von Alexander Terekhov vorgeschlagene, aber anstelle des „benannten Mutex“ wurde eine warteschlangenbasierte Sperre implementiert, die über die erforderlichen Eigenschaften der dynamischen Selbstinitialisierung und -zerstörung verfügt. Auch diese Sperre ist effizient. Der ABI bleibt davon unberührt, da sich die Größe von pthread_once_t nicht geändert hat und sich PTHREAD_ONCE_INIT nicht geändert hat. Anwendungen, die einen Blick in pthread_once_t werfen, das eigentlich undurchsichtig sein sollte, werden jedoch nicht funktionieren.
(19.05.2005)
Alle Fehlerbehebungen und neuen Funktionen in dieser Version wurden in Version 1.10.0 zurückportiert.
Diese Version wurde sowohl auf Einprozessor- als auch auf Mehrprozessorsystemen getestet (die Testsuite bestanden). Vielen Dank an Tim Theisen von TomoTherapy für die umfassende Durchführung der MP-Tests und für die Bereitstellung wichtiger Beobachtungen und Daten, wenn Fehler erkannt werden.
(09.05.2005)
Das Paket enthält jetzt einen Referenzdokumentationssatz, der aus HTML-formatierten Handbuchseiten im Unix-Stil besteht, die für die Konsistenz mit pthreads-win32 bearbeitet wurden. Das Set kann auch online gelesen werden unter: http://sources.redhat.com/pthreads-win32/manual/index.html
Nochmals vielen Dank an Tim Theisen für die Ausführung der Testsuite-Vorabversion auf einem MP-System.
Alle Fehlerbehebungen und neuen Funktionen in dieser Version wurden in Version 1.9.0 zurückportiert.
Die geänderte Implementierung vermeidet die Notwendigkeit des problematischen HANDLE und fordert den Speicher zurück, sobald entweder der Schlüssel gelöscht wird ODER der Thread beendet wird, je nachdem, was zuerst eintritt.
Vielen Dank an Richard Hughes von Aculab für die Identifizierung und Lokalisierung des Lecks.
TSD-Schlüsseldestruktoren werden jetzt bis zu PTHREAD_DESTRUCTOR_ITERATIONS-Mal statt nur einmal verarbeitet. PTHREAD_DESTRUCTOR_ITERATIONS ist seit einiger Zeit in pthread.h definiert, wird aber nicht verwendet.
Behebung eines Semaphor-Abrechnungswettlaufs zwischen sem_post/sem_post_multiple und sem_wait-Abbruch. Dies ist das gleiche Problem wie bei sem_timedwait, das in der letzten Version behoben wurde.
sem_init, sem_post und sem_post_multiple prüfen nun, ob die Semaphoranzahl niemals _POSIX_SEM_VALUE_MAX überschreitet.
Obwohl sigwait() nichts weiter als ein No-Op ist, sollte es zumindest ein Abbruchpunkt sein, um mit dem Standard konsistent zu sein.
stress1.c – versucht, Probleme in der Bedingungsvariablen- und Semaphor-Zeitwartelogik aufzudecken. Dieser Test wurde von Stephan Muellers Beispieltestcode inspiriert, der zur Identifizierung des sem_timedwait-Fehlers aus der letzten Version verwendet wurde. Es ist nicht Teil der regulären Testsuite, da die Ausführung eine Weile dauern kann. Um es auszuführen: nmake clean VC-stress
tsd2.c – testet, dass Schlüsseldestruktoren erneut ausgeführt werden, wenn der TSD-Schlüsselwert nach der Ausführung der Destruktorroutine nicht NULL ist. Testet außerdem, ob pthread_setspecial() und pthread_getspecial() von Destruktoren aus aufgerufen werden können.
(26.04.2005)
Es gibt derzeit keinen Plan, eine Version 3.0.0 zu veröffentlichen, um Probleme in pthread_once() zu beheben. Andere mögliche Implementierungen von pthread_once werden für eine mögliche zukünftige Version noch untersucht, um die Komplexität der aktuellen Implementierung zu reduzieren.
Alle Fehlerbehebungen und neuen Funktionen in dieser Version wurden für Version 1.8.0 zurückportiert.
pthread_once-Rennen behoben (Fehler auf einem MP-System). Vielen Dank an Tim Theisen für die Durchführung umfassender Vorabtests auf seinem MP-System mit einer Reihe von Compilern: VC++ 6 VC++ 7.1 Intel C++ Version 8.0 Alle Tests bestanden. Es wurden auch einige kleinere Geschwindigkeitsverbesserungen vorgenommen.
Behebung eines Integer-Overrun-Fehlers in pthread_mutex_timedlock() – übersehen, als sem_timedwait() in Version 2.2.0 behoben wurde. Diese Routine gibt nicht mehr ENOTSUP zurück, wenn NEED_SEM definiert ist – es wird unterstützt (NEED_SEM ist nur für WinCE-Versionen vor 3.0 erforderlich).
Timeout-Fehler in sem_timedwait() behoben.
Beheben Sie mehrere Probleme im bedingt eingebundenen Code NEED_SEM. Der in NEED_SEM enthaltene Code wird für Systeme bereitgestellt, die keine W32-Semaphoren implementieren, wie z. B. WinCE vor Version 3.0. Eine alternative Implementierung von POSIX-Semaphoren wird mithilfe von W32-Ereignissen für diese Systeme erstellt, wenn NEED_SEM definiert ist. Dieser Code wurde in dieser Version komplett neu geschrieben, um den Großteil des standardmäßigen POSIX-Semaphorcodes wiederzuverwenden und insbesondere alle von pthreads-win32 unterstützten sem_*-Routinen zu implementieren. Tim Theisen führte die Testsuite auch über den NEED_SEM-Code auf seinem MP-System aus. Alle Tests bestanden.
Die Bibliothek wird jetzt fehlerfrei für den Borland Builder 5.5-Compiler erstellt.
pthread_once ist zu kompliziert – aber es funktioniert, soweit Tests das beurteilen können.
Die Borland-Version der DLL besteht einige Tests aufgrund einer Speicherleseausnahme nicht. Die Ursache ist noch nicht bekannt, ein Compilerfehler wurde jedoch nicht ausgeschlossen.
(12.04.2005)
Version 1.7.0 ist ein Backport der neuen Funktionen und Fehlerbehebungen in dieser Version. Siehe frühere Hinweise unter Version 2.0.0/Allgemein.
(04.04.2005)
Makefile-Ziele hinzugefügt, um statische Linkversionen der Bibliothek zu erstellen. Sowohl MinGW als auch MSVC. Bitte beachten Sie, dass dies keine Änderung der LGPL-Lizenzierung bedeutet, die immer noch bestimmte Bedingungen für die Verteilung von Software vorschreibt, die statisch mit dieser Bibliothek verknüpft ist.
Es gibt einen bekannten Fehler in pthread_once(). Der Abbruch der init_routine legt ein potenzielles Hungerproblem (dh einen Deadlock) offen, wenn ein wartender Thread eine höhere Priorität als der initiierende Thread hat. Dieses Problem wird in Version 3.0.0 der Bibliothek behoben.
Behebung eines Integer-Overrun-Fehlers in sem_timedwait(). Kevin Lussier
Korrigieren Sie Präprozessoranweisungen für statische Verknüpfungen. Dimitar Panayotov
(16.03.2005)
(16.03.2005)
Diese Version stellt eine ABI-Änderung dar und die Benennung der DLL-Version wurde von 1 auf 2 erhöht, z. B. pthreadVC2.dll.
Version 1.4.0 portiert die in dieser Version enthaltenen neuen Funktionen zurück. Bitte verteilen Sie DLLs, die aus dieser Version erstellt wurden, mit Updates an Anwendungen, die auf pthreads-win32 Version 1.xx erstellt wurden
Die Paketbenennung hat sich geändert und das Snapshot-Datum durch die Versionsnummer + beschreibende Informationen ersetzt. Diese Version ist beispielsweise „pthreads-win32-2-0-0-release“.
Version 1.3.0
Version 1.2.0
Version 1.1.0
Version 1.0.0
Dieser Snapshot behebt hauptsächlich den in Snapshot-2004-11-03 eingeführten Kondvar-Fehler. Die DLL-Versionierung wurde auch enthalten, damit Anwendungen zur Laufzeit die Microsoft-kompatiblen DLL-Versionsinformationen überprüft und das DLL-Naming-System für ABI- und Major-API-Änderungen (Nicht-Rückwärts-kompatibler) erweitert werden können. Weitere Informationen finden Sie in der Datei ReadMe -Datei.
Eine Versionsressource im Microsoft-Stil wurde der DLL für Anwendungen hinzugefügt, die die DLL-Kompatibilität zur Laufzeit überprüfen möchten.
PThreads-Win32-DLL-Namen wurde erweitert, damit inkompatible DLL-Versionen im selben Dateisystem nebeneinander existieren können. Details finden Sie in der LEADME -Datei, aber kurz: Während sich die Versionsinformationen in der DLL von nun an mit jeder Version ändern, ändern sich die Namen der DLL -Version nur dann, wenn die neue DLL nicht mit älteren Anwendungen kompatibel ist.
Das Versionsschema wurde von GNU Libtool ausgeliehen, und das DLL -Namensschema stammt von Cygwin. Vorausgesetzt, dass die Nummerierungsregeln im LIBTOOL-Stil geehrt werden, stellt das Cygwin DLL-Namensschema automatisch sicher, dass die Änderungen des DLL-Namens minimal sind und Anwendungen eine inkompatible PThreads-Win32-DLL nicht laden.
Diejenigen, die die vorgefertigten DLLs verwenden, werden feststellen, dass die DLL/LIB-Namen in diesem Schnappschuss ein neues Suffix (1) haben. EG pthreadvc1.dll usw.
Bestimmte POSIX -Makros haben sich geändert.
Diese Änderungen sollen der einzelnen Unix -Spezifikationsversion 3 entsprechen, in der angegeben ist, dass die Anwendungen, wenn sie auf 0 (Null) oder nicht definiert sind, sysconf () zur Ermittlung ihrer Werte zur Laufzeit verwenden können. pthreads-win32 implementiert nicht sysconf ().
Die folgenden Makros sind nicht mehr undefiniert, sondern definiert und auf -1 festgelegt (nicht implementiert):
_POSIX_THREAD_ATTR_STACKADDR
_POSIX_THREAD_PRIO_INHERIT
_POSIX_THREAD_PRIO_PROTECT
_POSIX_THREAD_PROCESS_SHARED
Die folgenden Makros sind definiert und auf 200112L festgelegt (implementiert):
_POSIX_THREADS
_POSIX_THREAD_SAFE_FUNCTIONS
_POSIX_THREAD_ATTR_STACKSIZE
_POSIX_THREAD_PRIORITY_SCHEDULING
_POSIX_SEMAPHORES
_POSIX_READER_WRITER_LOCKS
_POSIX_SPIN_LOCKS
_POSIX_BARRIERS
Die folgenden Makros sind definiert und auf geeignete Werte eingestellt:
_POSIX_THREAD_THREADS_MAX
_POSIX_SEM_VALUE_MAX
_POSIX_SEM_NSEMS_MAX
PTHREAD_DESTRUCTOR_ITERATIONS
PTHREAD_KEYS_MAX
PTHREAD_STACK_MIN
PTHREAD_THREADS_MAX
Aus diesem Snapshot erzeugte DLLs können mit älteren Anwendungen nicht ohne Neukompilieren der Anwendung verwendet werden, da eine Änderung zu pthread_t zur Bereitstellung von eindeutigen POSIX -Thread -IDs bereitgestellt wird.
Obwohl dieser Snapshot die erweiterte Testsuite übergeht, sind viele der Änderungen ziemlich wichtig, und einige Anwendungen können ein anderes Verhalten als zuvor aufweisen. Hoffentlich wird jedes veränderte Verhalten darauf zurückzuführen, dass die Bibliothek besser in ihrem Job ist, nicht schlechter.
pthread_create () akzeptiert NULL nicht mehr als Thread Reference Arg. Ein Segfault (Speicherzugriffsfehler) führt zu und es wird kein Thread erstellt.
pthread_barier_wait () fungiert nicht mehr als Stornierungspunkt.
Fix potenzielle Rennbedingung in pThread_once ()
Für die Kompatibilität hinzugefügt: pthread_recursive_mutex_initializer, pthread_errorcheck_mutex_initializer, pthread_recursive_mutex_initializer_np, pthread_errorcheck_mutex_initializer_np
Erste Unterstützung für den digitalen Mars -Compiler
Schnellere Mutexes. Diese wurden nach einem von Alexander Terekhov bereitgestellten Modell umgeschrieben, das die Kernel -Raumprüfungen reduziert, und beseitigt einige zusätzliche kritische Abschnitte, die zur Verwaltung eines Rennens zwischen Timedlock -Ablauf und Entsperren verwendet werden. Bitte beachten Sie, dass die neuen Mutexes keine strikte absolute FIFO-Planung von Mutexes erzwingen, jedoch sollte ein Sperraufnahme außerhalb der Ordnung sehr selten sein.
Schnellere Semaphoren. Nach einem ähnlichen Modell wie Mutexes oben wurden diese um vorläufige Benutzerspeicherprüfungen umgeschrieben.
sem_getValue () gibt nun die Anzahl der Kellner zurück.
Die POSIX -Thread -ID hat jetzt viel stärkere Einzigartigkeitseigenschaften. Die Bibliothek garrantees, nicht dieselbe Thread -ID für mindestens 2^(WordSize) Fadenzerstörung/Erstellungszyklen wiederzuverwenden.
Semaphore4.c: Tests Stornierung des neuen Sem_waits ().
semaphore4t.c: Ebenso für sem_timedwait ().
rwlock8.c: Tests und Zeiten die langsamen Ausführungspfade von R/W -Schlössern und die Lebensläufe, Mutexes und Semaphoren, auf denen sie aufgebaut sind.
Versuchen Sie, Watcom in die Liste der Compiler hinzuzufügen, die die Bibliothek erstellen können. Dies scheiterte am Ende aufgrund seines nicht-threadbewussten Errno. Die Bibliothek baut, aber die Testsuite schlägt fehl. Weitere Informationen finden Sie unter Readme.Watcom.
Hinweis: Wenn Sie in Ihrer Anwendung keine asynchronisierte Stornierung verwenden oder keine Threads stornieren müssen, die auf Systemressourcen wie der Netzwerk-E/A blockiert sind, ist die Standard-nicht-preemptive Async-Stornierung wahrscheinlich gut genug. Pthreads-Win32 erstellt jedoch die Verfügbarkeit dieser Komponenten zur Laufzeit automatisch.
Alle Beratung, die in Büchern und an anderer Stelle zur Unerwünschbarkeit der Verwendung von Async -Stornierungen in jeder Anwendung verfügbar sind, steht weiterhin. Diese Funktion ist jedoch eine willkommene Ergänzung in Bezug auf die Konformität der Bibliothek mit dem POSIX -Standard.
Reinigung des Thread -Prioritätsmanagements. Insbesondere versucht die Einstellung der Thread -Priorität nun, ungültige Win32 -Werte innerhalb des Bereichs zuzuordnen, der von pled_get_priority_min/max () auf nützliche Werte zurückgegeben wird. Siehe Readme.nonportable unter "Thread Priority".
pthread_getSchedparam () gibt nun die Priorität zurück, die durch den neuesten Aufruf an pthread_setchedparam () oder von pthread_create () nach dem Standard festgelegt wurde. Zuvor hat pThread_getSchedParam () die zum Zeitpunkt des Anrufs ausgeführte Thread -Priorität fälschlicherweise zurückgegeben, die möglicherweise angepasst oder vorübergehend beworben/herabgestuft wurde.
plant_get_priority_min () und pled_get_priority_max () geben nun -1 beim Fehler zurück und setzen Sie Errno. Zuvor haben sie den Fehlerwert fälschlicherweise direkt zurückgegeben.
pthread_self () würde den neu erstellten impliziten POSIX -Thread -Handle freien, wenn DuplicateHandle fehlschlägt, anstatt ihn zu recyceln (sehr unwahrscheinlich).
pthread_exit () war weder frei und recycling die POSIX -Threadstruktur für implizite POSIX -Threads.
Seit der ursprünglichen Implementierung von John Bosom hat die Bibliothek es nicht posix initialisierte Threads (Win32-Threads) dazu ermöglicht, PThreads-Win32-Routinen aufzurufen und daher mit POSIX-Threads zu interagieren. Dies geschieht durch das Erstellen einer POSIX-Thread-ID im Fliege für den Win32-Thread, der nach dem Erstellen einer vollständigen reziploren Interaktion ermöglicht. Dies erstreckte sich nicht auf die Stornierung von Threads (asynchronisiert oder aufgeschoben). Jetzt tut es das.
Jeder Thread kann von einem anderen Thread (Win32 oder POSIX) abgebrochen werden, wenn der Wert des früheren Threads des POSIX pThread_t des Threads bekannt ist. Es sind TSD -Zerstörer und POSIX -Aufräumer werden ausgeführt, bevor der Thread mit einem Exit -Code von pThread_canceled (mit getExitCodhead () abgerufen) beendet wird.
Dies ermöglicht einem Win32 -Thread beispielsweise POSIX -CV -Routinen auf die gleiche Weise, wie POSIX -Threads mit pThread_cond_wait () Stornierbarkeit und Reinigungshandlern (pthread_cond_wait () ein POSIX -Stornierungspunkt).
Durch Hinzufügen von Stornierung sollten Win32 -Threads jetzt in der Lage sein, alle Posix -Threads zu nennen, die sinnvoll sind, einschließlich Semaphoren, Mutexes, Bedingungsvariablen, Lese-/Schreiben von Sperrs, Barrieren, Spinlocks, TSD, Reinigungs -Push/Pop, Stornierung, pthread_exit, Zeitplanung usw. .
Beachten Sie, dass diese POSIX-Thread-IDs der Fliege im Fliege als abgetrennter (nicht verbindbar) mit aufgeschobener Stornierungstyp initialisiert werden. Die POSIX -Thread -ID wird automatisch von POSIX -Routinen erstellt, die ein POSIX -Handle benötigen (es sei denn, die Routine benötigt natürlich einen pthread_t als Parameter). Ein Win32 -Thread kann feststellen, dass es sich um eine eigene POSIX -Thread -ID handelt, indem er pthread_self () aufgerufen wird, wodurch das Handle bei Bedarf erstellt wird und den Wert pThread_t zurückgibt.
Testen Sie die obige neue Funktion.
Dieser Schnappschuss behebt eine zufällige Korruption auf neue Testfallquellen. Der Bibliotheksquellcode gibt keine Änderungen.
Verschiedene Änderungen, um die ARG -Überprüfung zu verschärfen und mit späteren Versionen von Mingw32 und MSYSDTK zu arbeiten.
pthread_getSchedParam () usw., feste Überprüfung der gefährlichen Gewinde Gültigkeit.
sem_timedwait () verwendet nun engere Überprüfungen über unangemessene Abstimungswerte - was zu unerwarteten Zeitüberschreitungswerten führen würde.
ptw32_cond_wait_cleanUp () verbraucht keine mysteriösen CV -Signale mehr, sondern kann auf falsche Aufwachen erzeugen. Es wird angenommen, dass der Anruf sem_timedwait () ein CV -Signal verbraucht, das dies nicht sollte.
Es wurde ein Speicherleck in ptw32_threaddestroy () für implizite Threads behoben.
Behobene Potenzial für Deadlock in pThread_cond_destroy (). Ein Deadlock kann für statisch deklarierte CVS (pThread_cond_initializer) auftreten, wenn ein Thread versucht, die Bedingungsvariable zu zerstören, während ein anderer versucht, ihn dynamisch zu initialisieren.
Früher, wenn nicht definiert, wurde der Reinigungsstil automatisch aus dem Compiler/der Sprache ermittelt, und eines der folgenden folgenden wurde entsprechend definiert:
PTW32_CLEANUP_SEH MSVC only
PTW32_CLEANUP_CXX C++, including MSVC++, GNU G++
PTW32_CLEANUP_C C, including GNU GCC, not MSVC
Diese definieren den Aufräumestil (siehe pThread.h) und vor allem die Art und Weise, wie Stornierung und Thread -Ausgang (über pthread_exit) durchgeführt werden (siehe Routine PTW32_Throw () in privat.c).
Kurz gesagt, die Ausnahmenversionen der Bibliothek werfen eine Ausnahme aus, wenn ein Thread abgebrochen wird oder beendet (über pthread_exit ()), der von einem Handler in der Thread -Startroutine gefangen wird, so dass der richtige Stapelabwickeln auftritt, unabhängig davon, wo die Thread ist, wenn er abgesagt wird oder über pThread_exit () abgebrochen wird.
In diesem und zukünftigen Snapshots, es sei denn, der Build definiert explizit (z. B. über eine Compiler -Option) PTW32_Cleanup_Seh, PTW32_Cleanup_cxx oder ptw32_cleanup_c, dann wird der Build jetzt immer standardmäßig ptw32_cleanup_c style cleanup. Dieser Stil verwendet setJMP/longJMP in den Implementierungen von Stornierungen und pthread_exit und wird daher nicht mit den Anwendungen mit dem Stapel abwickelt (z. B. C ++ - Apps). Dies ist für die Konsistenz mit den meisten aktuellen kommerziellen Unix -Possix -Threads -Implementierungen gedacht. Die TRU64 von Compaq kann eine Ausnahme sein (kein Wortspiel beabsichtigt) und einen möglichen zukünftigen Trend.
Obwohl es vorher nicht klar dokumentiert wurde, ist es weiterhin erforderlich, Ihre Anwendung mit demselben PTW32_Cleanup_* Define zu erstellen, wie es für die Version der Bibliothek verwendet wurde, mit der Sie verlinkt wurden, damit die richtigen Teile von pthread.h enthalten sind. Das heißt, die möglichen Definieren erfordern die folgenden Bibliotheksversionen:
PTW32_CLEANUP_SEH pthreadVSE.dll
PTW32_CLEANUP_CXX pthreadVCE.dll or pthreadGCE.dll
PTW32_CLEANUP_C pthreadVC.dll or pthreadGC.dll
EG, unabhängig davon, ob Ihre App C oder C ++ ist, wenn Sie mit pthreadvc.lib oder libpThreadgc.a in Verbindung stehen, müssen Sie PTW32_Cleanup_c definieren.
Der Sinn von all dem ist: Wenn Sie eines dieser explizit nicht explizit definiert haben, wurden die Standardeinstellungen, wie oben in diesem Abschnitt beschrieben, verwendet.
Dies ändert sich jetzt, wie oben erläutert, aber zu versuchen, dies klarer zu machen. Hier ist ein Beispiel:
Wenn Sie Ihre Anwendung mit MSVC ++ - IE unter Verwendung von C ++ - Ausnahmen erstellt haben und eines von PTW32_Cleanup_*nicht explizit definieren, wurde PTWED.H. Sie hätten mit pThreadvce.dll in Verbindung gebracht werden sollen, was Stapel entspannt.
Wenn Sie jetzt Ihre Anwendung wie zuvor erstellen, setzt PThread.h jetzt automatisch PTW32_Cleanup_c als Standardstil ein und Sie müssen sich mit pThreadvc.dll verlinken. Die Stapelabwicklung tritt nun nicht auf, wenn ein Thread abgebrochen wird, oder der Thread ruft pthread_exit () auf.
Ihre Bewerbung wird sich jetzt höchstwahrscheinlich in früheren Versionen und auf nicht offensichtliche Weise anders verhalten. Höchstwahrscheinlich ist, dass lokal instanziierte Objekte nach dem Abbrechen eines Fadens nicht zerstört oder gereinigt werden.
Wenn Sie das gleiche Verhalten wie zuvor wünschen, müssen Sie jetzt ptw32_cleanup_c ++ definieren, indem Sie eine Compiler -Option explizit verwenden und mit pthreadvce.dll wie zuvor verknüpfen.
Warum machen wir den Standardstil weniger ausnahmslos freundlich? Da keine kommerzielle Unix -POSIX -Threads -Implementierung es ermöglicht, sich für Stack -Abwickeln zu entscheiden. Daher ist es gefährlich, es in pThread-win32 als Ausfall bereitzustellen. Wir bieten immer noch die Auswahl, aber wenn Sie sich nicht bewusst für das andere entscheiden, werden Ihre PThreads -Anwendungen nun auf ähnliche Weise ausgeführt oder abstürzen, unabhängig von der von Ihnen verwendeten Threads -Plattform. Zumindest ist dies die Hoffnung.
Warum nicht die Ausnahmenversionen der Bibliothek ganz entfernen? Es gibt einige Gründe:
Um kleinere Bildgrößen für Anwendungen zu erstellen, die statisch mit der Bibliothek verknüpfen, wurden die meisten Routinen in einzelnen Quellcodedateien unterteilt.
Dies wird so geschehen, dass es rückwärtskompatibel ist. Die alten Quelldateien werden wiederverwendet, um die einzelnen Routinedateien in größere Übersetzungseinheiten (über eine Reihe von #includes) zu verwandeln, damit der Compiler nach Möglichkeit optimieren kann, z. B. durch Inlining, die nur innerhalb derselben Übersetzungseinheit durchgeführt werden können.
Es ist auch möglich, die gesamte Bibliothek zu erstellen, indem die einzelne Datei mit dem Namen "pThread.c" zusammengestellt wird, die nur alle sekundären Kongregationsquellendateien ##Includiert. Der Compiler kann dies möglicherweise verwenden, um mehr Routinen zu beeinträchtigen.
Obwohl der GNU -Compiler in der Lage ist, Bibliotheken mit der notwendigen Trennung (den Switch -Segmente) zu produzieren, haben AFAIK, MSVC und andere Compiler diese Funktion nicht.
Da ich Makefiles und Befehlszeilenkompilation verwende, weiß ich nicht, was diese Reorganisation unter den IDE-Projektdateibenutzern durcheinander bringen kann. Sie sollten in der Lage sein, Ihre vorhandenen Projektdateien ohne Änderung weiter zu verwenden.
pthread_num_processors_np ():
Gibt die Anzahl der Prozessoren im System zurück, die dem Prozess zur Verfügung stehen, wie aus der Prozessor -Affinitätsmaske ermittelt.
pthread_timechange_handler_np ():
Verbesserung der Toleranz gegenüber Bediener oder dem Zeitdienst initiierte Systemtaktänderungen.
Diese Routine kann von einer Anwendung aufgerufen werden, wenn sie eine WM_Timechange -Nachricht vom System empfängt. Derzeit sendet es alle Bedingungsvariablen, sodass wartende Themen aufwachen, ihre Bedingungen neu bewerten und ihre zeitgesteuerten Wartezeiten bei Bedarf neu starten können.
Da Win95 keine liefert, enthält die Bibliothek jetzt ihre eigene Routine für InterlockedCompareExChange (), die immer dann verwendet wird, wenn Windows es nicht bereitstellt. InterlockedCompareExChange () wird verwendet, um Spinlocks und Barrieren sowie in Mutexen zu implementieren. Diese Routine basiert auf der CMPXCHG -Maschinenbehörde, die auf i386 CPUs nicht verfügbar ist. Diese Bibliothek (ab Snapshot 20010712) wird daher auf i386 -Prozessorplattformen nicht mehr unterstützt.
Nur für die Quellcode -Portabilität - RWLOCKS können noch nicht prozessfrei sein.
pthread_rwlockattr_init()
pthread_rwlockattr_destroy()
pthread_rwlockattr_setpshared()
pthread_rwlockattr_getpshared()
Wie im neuen POSIX -Standard und in der Einzel -Unix -Spezifikation Version 3 definiert:
sem_timedwait()
pthread_mutex_timedlock() - Alexander Terekhov and Thomas Pfaff
pthread_rwlock_timedrdlock() - adapted from pthread_rwlock_rdlock()
pthread_rwlock_timedwrlock() - adapted from pthread_rwlock_wrlock()
[Noch nicht für G ++]
Dies geschah, um Konflikte zu verhindern.
Handle, DWORD und NULL werden in pThread vorübergehend definiert.
Um nicht nur die Notwendigkeit der Datei pThread.def zu vermeiden, sondern auch die Leistung zu verbessern. Offensichtlich generiert das Erklärungsfunktionen mit Dllimport einen direkten Aufruf der Funktion und vermeidet den Aufwand eines Stub -Funktionsaufrufs.
Dies kann durch die Anwendungen transparent gemacht werden .
Stornierung Einmal in einem Thread gestartet, kann jetzt nicht unbeabsichtigt doppelt abgesagt werden. Das heißt, sobald ein Thread begonnen hat, ist die Stornierungsläufe, die Stornierung deaktiviert und eine anschließende Abbrechenanforderung gibt einen Fehler zurück (ESRCH).
Errno: Eine falsche Compiler -Anweisung hat eine lokale Version von Errno anstelle des Win32 errno verwendet. Beide Instanzen sind thread-sicher, aber Anwendungen, die Errno nach einem Pthreads-Win32-Anruf überprüfen, wären falsch. Das Beheben dieses Fixes hat auch eine schlechte Compiler -Option im Testsuite ( /mt sollte /md) festgelegt, das benötigt wird, um mit der richtigen Bibliothek msvcrt.lib zu verknüpfen.
Hinzugefügt werden
Hinzugefügt werden
Neu:
Renamed DLL and LIB files:
pthreadVSE.dll (MS VC++/Structured EH)
pthreadVSE.lib
pthreadVCE.dll (MS VC++/C++ EH)
pthreadVCE.lib
pthreadGCE.dll (GNU G++/C++ EH)
libpthreadw32.a
Both your application and the pthread dll should use the
same exception handling scheme.
Fehler behoben:
MSVC++ C++ exception handling.
Einige neue Tests wurden hinzugefügt.
Neu:
asynchronous cancellation on X86 (Jason Nye)
Makefile compatible with MS nmake to replace
buildlib.bat
GNUmakefile for Mingw32
tests/Makefile for MS nmake replaces runall.bat
tests/GNUmakefile for Mingw32
Fehler behoben:
kernel32 load/free problem
attempt to hide internel exceptions from application
exception handlers (__try/__except and try/catch blocks)
Win32 thread handle leakage bug
(David Baggett/Paul Redondo/Eyal Lebedinsky)
Einige neue Tests wurden hinzugefügt.
Fehler behoben:
ctime_r macro had an incorrect argument (Erik Hensema),
threads were not being created
PTHREAD_CANCEL_DEFERRED. This should have
had little effect as deferred is the only
supported type. (Ross Johnson).
Einige Kompatibilitätsverbesserungen wurden hinzugefügt, z.
pthread_setcancelstate accepts NULL pointer
for the previous value argument. Ditto for
pthread_setcanceltype. This is compatible
with Solaris but should not affect
standard applications (Erik Hensema)
Einige neue Tests wurden hinzugefügt.
Fehlerbehebung - Stornierung von Threads, die auf Zustandsvariablen warten, funktioniert jetzt ordnungsgemäß (Lorin Hochstein und Peter Slacik)
Behebung der Ausnahmestapel -Reinigung Wenn Sie pthread_exit aufrufen ()
Fehler in Bedingungsvariablen behoben - (Peter Slacik): - zusätzliche Streitprüfungen - Passen Sie die Anzahl der Wartefäden nach zeitgesteuerter Kondvar -Zeitüberschreitung ordnungsgemäß an.
Einige kleinere Fehler wurden behoben. Weitere Informationen finden Sie in der Datei ChangeLog.
Einige weitere POSIX 1B -Funktionen sind jetzt enthalten, aber Ony gibt einen Fehler (Enosys) zurück, wenn er aufgerufen wird. Sie sind:
sem_open
sem_close
sem_unlink
sem_getvalue
Einige POSIX 1B -Funktionen, die intern unterstützt wurden, sind jetzt als exportierte Funktionen erhältlich:
sem_init
sem_destroy
sem_wait
sem_trywait
sem_post
sched_yield
sched_get_priority_min
sched_get_priority_max
Einige kleinere Fehler wurden behoben. Weitere Informationen finden Sie in der Datei ChangeLog.
Erstveröffentlichung.
