घर
Top.Mail.Ru Yandeks.Metrika
मंच: "शुरुआती";
वर्तमान संग्रह: 2017.11.12;
डाउनलोड करें: [xml.tar.bz2];

नीचे

SendMessage के माध्यम से सिंक करें इसी तरह की शाखाएँ खोजें


Alex4445   (2015-12-15 22:37) [0]

प्रकार TMyForm = वर्ग (TForm) ... प्रक्रिया SyncMsg (var T: TMessage); संदेश WM_USER + 1; समाप्त वर MyForm: TMyForm; प्रक्रिया TMyForm.SyncMsg (var T: TMessage); शुरू CSL.Send ("दर्ज करें"); // CodeSiteLogger - लॉगिंग सिस्टम नींद (2000); CSL.Send ("छुट्टी"); समाप्त;

TMyThread = वर्ग (TThread) प्रक्रिया निष्पादित; ओवरराइड; समाप्त; प्रक्रिया TMyThread.Execute; शुरू जबकि (समाप्त नहीं) करते हैं SendMessage (MyForm.Handle, WM_USER + 1,0,0); नींद (100); समाप्त; समाप्त;

एक ही प्रकार के कई धागे बनाए जाते हैं, जो SendMessage के माध्यम से, मुख्य थ्रेड में एक निश्चित कोड (इस मामले में, एक लॉग + स्लिप) को निष्पादित करते हैं।

मुझे लॉग में देखने की उम्मीद है:

दर्ज
छोड़ना
दर्ज
छोड़ना
...
दर्ज
छोड़ना
...

यही है, मुख्य थ्रेड प्रक्रियाएँ SendMessages क्रमिक रूप से।

समझा

दर्ज
छोड़ना
दर्ज // ???
दर्ज // ???
छोड़ना
दर्ज
छोड़ना
...

यह कैसा है? पिछला SendMesssage पिछले एक के समाप्त होने तक कैसे चलना शुरू हुआ?
या यह लकड़हारे के काम से जुड़ी "चाल" है?



Rouse_ ©   (2015-12-16 00:03) [1]

अधिक संभावना एक लकड़हारा, पहली नज़र में सिंक्रनाइज़ेशन मान्य है



sniknik ©   (2015-12-16 01:45) [2]

> पहली नज़र में सिंक्रोनाइज़ेशन मान्य है
मुश्किल से। SendMessage तत्काल निष्पादन, एक कतार के बिना, प्रक्रिया कोड अवरुद्ध नहीं है, कोई महत्वपूर्ण खंड नहीं है। जब पहला नींद में होता है तो दूसरा थ्रेड अपने सेंडमासेज को लागू करने से रोकता है। नींद, सिद्धांत रूप में, मौजूदा एक के निष्पादन को "नम" करने और अन्य धागे को "साँस" करने के लिए आवश्यक है। वे यहाँ हैं। यह वास्तव में कोड के लिए एक प्रत्यक्ष कॉल है, सभी एक है जिसे फ़ंक्शन सीधे स्ट्रीम में वर्णित किया गया है (या जहां कोई फर्क नहीं पड़ता) कहा जाता है।
PostMessage में परिवर्तन, घटना कतार स्थिति को ठीक करना चाहिए।
या
+, एक और विकल्प
> यह कैसे संभव है?
और एन्टर-एस और लीव की संख्या गिनें। पहला मामला कोई और नहीं इस अर्थ में, शायद एक "सहज", भूल गए संदेश उसी कोड के साथ दूसरी जगह से आता है?

IMHO, लकड़हारे के लिए आपको अलग थ्रेड + PostThreadMessage की आवश्यकता होती है, न कि फॉर्म पर मुख्य c ईवेंट की।



Alex4445   (2015-12-16 12:02) [3]


> शायद ही। SendMessage तत्काल निष्पादन, कतार के बिना,
> प्रक्रिया कोड अवरुद्ध नहीं है, कोई महत्वपूर्ण अनुभाग नहीं है।
> कुछ भी इसके SendMessage को लागू करने से दूसरे धागे को रोकता नहीं है
> पहली बार जब सोने के लिए। नींद, सिद्धांत रूप में, की जरूरत है
> करंट के निष्पादन को "नम" करने के लिए, और "साँस" दें
> अन्य सूत्र। वे यहाँ हैं। यह वास्तव में है
> प्रत्यक्ष कोड कॉल, सभी एक जिसे फ़ंक्शन ने सीधे वर्णित किया है
> स्ट्रीम में (या जो भी हो
> IMHO, लकड़हारे के लिए आपको एक अलग थ्रेड की आवश्यकता होती है

जहां) को बुलाना है।
> PostMessage में परिवर्तन, घटना कतार को ठीक करना चाहिए
> स्थिति।


हम्म .. यह "आउट ऑफ टर्न" कैसे है?
संदेश पंक्ति के माध्यम से भेजें और पोस्ट करें, भेजें .. और पोस्ट के बीच का अंतर .. कि पहले पूरा होने की प्रतीक्षा कर रहा है, और दूसरा नहीं है।


> एंटर-एस और लीव की संख्या गिनें। पहला मामला नहीं है
> और?

नहीं। सब कुछ वैसा ही हो जैसा होना चाहिए।



Rouse_ ©   (2015-12-16 12:10) [4]

और रुक जाओ, लेकिन सुस्त - कोल्या सही है, उसने कई चुनौतियों के बारे में नहीं पढ़ा।
हां, दूसरे धागे से एक कॉल पहले से कोड के निष्पादन को निलंबित कर देगा, इसलिए इस मामले में महत्वपूर्ण अनुभाग की आवश्यकता है



Alex4445   (2015-12-16 13:02) [5]

प्रक्रिया TMyThread.Execute; शुरू जबकि (समाप्त नहीं) करते हैं FCS.Enter; // टीसीट्रेलसिसेक्शन SendMessage (MyForm.Handle, WM_USER + 1,0,0); FCS.Leave; नींद (100); समाप्त; समाप्त;

क्या ऐसा कोई कोड है?
SendMessage ही सिंक्रनाइज़ेशन की गारंटी नहीं देता है ???



Юрий Зотов ©   (2015-12-16 13:11) [6]

> बाद के SendMesssage की शुरुआत कैसे हुई
> पिछले एक पूरा होने तक?


और उसे कौन रोक रहा है? कोई नहीं। यहाँ एक संभावित परिदृश्य है:

1. पहला धागा SendMessage को निष्पादित करना शुरू कर दिया है, लेकिन अभी तक समाप्त नहीं हुआ है (सभी और अधिक क्योंकि स्लीप (2000) संदेश हैंडलर में है।

2. दूसरा धागा SendMessage को निष्पादित करना शुरू कर दिया, क्योंकि कोई भी इसे परेशान नहीं करता है।

एक महत्वपूर्ण अनुभाग (उदाहरण के लिए) की आवश्यकता है।



Alex4445   (2015-12-16 13:12) [7]

मेरी राय में, इस मामले में, सिंक्रनाइज़ेशन में सिंक्रनाइज़ेशन प्राप्त किया जाता है, अगर एक ही समय में कुछ अन्य डेटा SendMessage के माध्यम से प्रेषित होता है, तो हमें एक संभावित गतिरोध प्राप्त होता है

TMyThread = वर्ग (TThread) FCS: TCriticalSection; एफए: पूर्णांक; प्रक्रिया निष्पादित; ओवरराइड; संपत्ति FAA: पूर्णांक GetFA पढ़ें; समाप्त; प्रक्रिया TMyThread.GetFA; शुरू FCS.Enter; प्रयत्न परिणाम: = एफए; आखिरकार FCS.Leave; समाप्त; समाप्त; प्रक्रिया TMyThread.Execute; शुरू जबकि (समाप्त नहीं) करते हैं FCS.Enter; SendMessage (MyForm.Handle, WM_USER + 1, FAA, 0); // - डेडलॉक FCS.Leave; नींद (100); समाप्त; समाप्त;



Alex4445   (2015-12-16 13:15) [8]

और उसे कौन रोक रहा है? कोई नहीं। यहाँ एक संभावित परिदृश्य है: 1. पहला धागा SendMessage को निष्पादित करना शुरू कर दिया है, लेकिन अभी तक समाप्त नहीं हुआ है (सभी और अधिक क्योंकि स्लीप (2000) संदेश हैंडलर में है। 2. दूसरा धागा SendMessage को निष्पादित करना शुरू कर दिया, क्योंकि कोई भी इसे परेशान नहीं करता है। एक महत्वपूर्ण अनुभाग (उदाहरण के लिए) की आवश्यकता है।

ए ... स्पष्ट रूप से मुझे निष्पादन में एक भ्रम है।

मैंने यह मान लिया कि संदेश कतार में मुख्य धागा SendMessage लेता है और उस पर तब तक लटका रहता है जब तक वह चलता है। और उसके बाद ही अगला मैसेज SendMessage लेता है



Alex4445   (2015-12-16 13:16) [9]

इसके अनुसार उदाहरण .. जाहिर है, भी, इस तरह होना चाहिए?

एफसीएसग्लोबल: टीसीरिटालसेक्शन; TMyThread = वर्ग (TThread) FCS: TCriticalSection; एफए: पूर्णांक; प्रक्रिया निष्पादित; ओवरराइड; संपत्ति FAA: पूर्णांक GetFA पढ़ें; समाप्त; प्रक्रिया TMyThread.GetFA; शुरू FCS.Enter; प्रयत्न परिणाम: = एफए; आखिरकार FCS.Leave; समाप्त; समाप्त; प्रक्रिया TMyThread.Execute; शुरू जबकि (समाप्त नहीं) करते हैं FCSGlobal.Enter; SendMessage (MyForm.Handle, WM_USER + 1, FAA, 0); FCSGlobal.Leave; नींद (100); समाप्त; समाप्त;



Юрий Зотов ©   (2015-12-16 13:17) [10]

> एलेक्स 4445 (16.12.15/13/02 5:XNUMX बजे) [XNUMX]
> SendMessage ही कोई सिंक्रनाइज़ेशन की गारंटी देता है ???

SendMessage केवल इस बात की गारंटी देता है कि जिस थ्रेड के कारण यह पहले संदेश को पूरी तरह से संसाधित करेगा और उसके बाद ही आगे बढ़ेगा।

और इससे कोई फर्क नहीं पड़ता कि संदेश प्रसंस्करण कोड फ़ॉर्म क्लास में लिखा गया है - इस कोड को वैसे भी SendMessage नामक थ्रेड में निष्पादित किया जाएगा।



sniknik ©   (2015-12-16 13:19) [11]

> हम्म .. वह कैसे "आउट ऑफ टर्न" है?
ठीक है, उस पर विचार करें, भेजें को केवल एक प्रत्यक्ष फ़ंक्शन कॉल माना जाता है, और यदि एक आवेदन में, तो एनालॉग -
प्रक्रिया TMyThread.Execute; शुरू जबकि (समाप्त नहीं) करते हैं MyForm.SyncMsg (nil); // मैं उदाहरण के लिए एक संरचना नहीं बनाऊंगा नींद (100); समाप्त; समाप्त;
खैर, vcl को छोड़कर / यह धारा से असंभव है, आदि।

> नहीं सब कुछ जैसा है वैसा ही होना चाहिए।
तो ठीक है, केवल पहला विकल्प।

> यहाँ कोड होना चाहिए?
खैर, आप क्यों बढ़ रहे हैं? महत्वपूर्ण खंड के साथ आप प्रतीक्षा करते समय केवल ब्रेक जोड़ेंगे, लॉगिंग के लिए क्यों? नाजुक है?

बस स्रोत कोड में PostMessage के साथ इसे बदलें और जांचें।



Юрий Зотов ©   (2015-12-16 13:21) [12]

हमें एफसीएस की आवश्यकता क्यों है?



Юрий Зотов ©   (2015-12-16 13:30) [13]

> मुझे लगा कि संदेश कतार में मुख्य धागा SendMessage लेता है
> और उस पर "लटका हुआ" जब तक यह चलता है

SendMessage हैंडलर को एक प्रत्यक्ष (यानी सामान्य) कॉल है, यह कतार में कुछ भी नहीं डालता है। आप HEAD स्ट्रीम से SendMessage को कॉल करते हैं - इस HEAD स्ट्रीम में, सभी संदेश प्रसंस्करण किया जाता है। और, इस तथ्य के बावजूद कि हैंडलर को मुख्य रूप में लिखा गया है, इसे वैसे भी HEAD स्ट्रीम (सेंडमेसेज भेजने वाले वाले) में निष्पादित किया जाता है।

और मुख्य धागे का इससे कोई लेना-देना नहीं है, यह इस समय की प्रतीक्षा कर रहा है जब HIS संदेश HIM कतार में दिखाई देता है: क्लासिक जबकि गेटमेज लूप (...)



Alex4445   (2015-12-16 13:31) [14]


> इस कोड को निष्पादित करने के बाद भी थ्रेड में होगा
> SendMessage।


यूरी, मैं स्पष्टीकरण मांगता हूं। ...

प्रक्रिया TMyThread.Execute; शुरू जबकि (समाप्त नहीं) करते हैं ... --- कोड थ्रेड 1 थ्रेड में निष्पादित किया जाता है मेसेज भेजें (....); --- कॉल थ्रेड थ्रेड 1 में किया जाता है नींद (100); ... --- कोड थ्रेड 1 थ्रेड में निष्पादित किया जाता है समाप्त; समाप्त; प्रक्रिया TMyForm.SyncMsg (var T: TMessage); शुरू CSL.Send ("दर्ज करें"); - कोड को मुख्य थ्रेड (एप्लिकेशन का मुख्य थ्रेड) में निष्पादित किया जाता है। नींद (2000); - कोड को मुख्य थ्रेड में निष्पादित किया जाता है CSL.Send ("छुट्टी"); - कोड को मुख्य थ्रेड में निष्पादित किया जाता है समाप्त;



Юрий Зотов ©   (2015-12-16 13:35) [15]

सामान्य तौर पर, यदि यह केवल लॉगिंग के बारे में है, तो मैं सहमत हूं कि आपको पोस्टमैसेज का उपयोग करने की आवश्यकता है न कि स्टीम करने की। वैसे, लॉग अधिक जानकारीपूर्ण हो जाएगा (खासकर यदि आप स्ट्रीम को कुछ नाम देते हैं और लॉग में इस नाम को किसी अन्य जानकारी के साथ प्रदर्शित करते हैं)।



Юрий Зотов ©   (2015-12-16 13:44) [16]

संपूर्ण TMyForm.SyncMsg विधि को थ्रेड 1 में निष्पादित किया जाएगा। यह मुख्य धागे में क्यों चलेगा? तथ्य यह है कि यह विधि फॉर्म क्लास में लिखी जाती है, कोई फर्क नहीं पड़ता।

Thread1 कॉल की एक श्रृंखला निष्पादित करता है:
- TMyThread.Execute - मेसेज भेजें - TMyForm.SyncMsg (सीधे SendMessage से कॉल किया गया) - नींद (100)

और मुख्य धागा इस श्रृंखला में बिल्कुल भी भाग नहीं लेता है। वह HIS टर्न में एक संदेश की प्रतीक्षा कर रहा है।



sniknik ©   (2015-12-16 13:45) [17]

> कोड को थ्रेड / मेन थ्रेड में निष्पादित किया जाता है
लॉग करने और देखने के लिए GetCurrentThreadId मान सहेजें।



Юрий Зотов ©   (2015-12-16 14:12) [18]

और अगर आप वास्तव में सिंक्रोनाइज़ेशन चाहते हैं, तो SendMessage को फेंक दें, इन सभी स्लीप्स को फेंक दें, महत्वपूर्ण सेक्शन को फेंक दें, मैसेज को भी फेंक दें। और सबसे सरल विकल्प को छोड़ दें: सिंक्रोनाइज़ के माध्यम से लॉग पर लिखें।

तभी दूसरी धारा का पूरा अर्थ मिट जाता है। इसलिए, इसे दूर फेंकने की आवश्यकता होगी। और सामान्य एकल-थ्रेडेड एप्लिकेशन रहेगा।
: ओ)



Alex4445   (2015-12-16 14:38) [19]

लोग, सवाल का लॉगिंग से कोई लेना-देना नहीं है।
लॉगिंग के लिए, CodeSiteLogger, जो डेल्फी XE के साथ शामिल है, का उपयोग किया जाता है।
यह जानने के लिए कि क्या क्रमिक रूप से एक के बाद एक कॉल किए जा रहे हैं सेंडमेसेज हैंडलर में लॉग जोड़े गए।

यूनिट Unit1; इंटरफेस का उपयोग करता है Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls; प्रकार TMyForm = वर्ग (TForm) btn1: TButton; प्रक्रिया btn1Click (प्रेषक: TObject); निजी {निजी घोषणाएँ} जनता {सार्वजनिक घोषणाएँ} प्रक्रिया SyncMsg (var T: TMessage); संदेश WM_USER + 1; समाप्त; TThread1 = वर्ग (TThread) प्रक्रिया निष्पादित; ओवरराइड; समाप्त; वर MyForm: TMyForm; कार्यान्वयन यूएसएस कोडसाइटॉगिंग; {$ R * .dfm} {} TThread1 प्रक्रिया TThread1.Execute; शुरू FreeOnTerminate: = सत्य; CodeSite.Send ("थ्रेड एक्सक्यूट दर्ज करें", GetCurrentThreadId); SendMessage (MyForm.Handle, WM_USER + 1,0,0); CodeSite.Send ("थ्रेड थ्रेड एक्स्यूट्यूट"); समाप्त; {} TMyForm प्रक्रिया TMyForm.btn1 क्लिक करें (प्रेषक: TObject); शुरू CodeSite.Send ("बटन क्लिक किया गया"); TThread1.Create; समाप्त; प्रक्रिया TMyForm.SyncMsg (var T: TMessage); शुरू CodeSite.Send ("संदेश दर्ज करें"); नींद (2000); CodeSite.Send ("संदेश से बाहर निकलें"); समाप्त; समाप्त।

लकड़हारा संदेश

बटन पर क्लिक करें थ्रेड 1736
थ्रेड एक्सक्यूट थ्रेड 7656 दर्ज करें
संदेश थ्रेड 1736 दर्ज करें
संदेश थ्रेड से बाहर निकलें 1736
थ्रेड थ्रेड निष्पादित थ्रेड 7656



Юрий Зотов ©   (2015-12-16 14:48) [20]

लॉग के चयनित भाग कहाँ से आए? कोड में कोई भी नहीं हैं।
बटन पर क्लिक करें थ्रेड 1736 1736 थ्रेड एक्सक्यूट थ्रेड 7656 दर्ज करें संदेश थ्रेड 1736 दर्ज करें संदेश थ्रेड से बाहर निकलें 1736 थ्रेड थ्रेड निष्पादित थ्रेड 7656 / CODE>



Alex4445   (2015-12-16 14:59) [21]

यह स्वयं SendSiteLogger को Send () हैंडलर में जोड़ता है;
दरअसल, प्रयोग की शुद्धता के लिए
CodeSite.Send () OutPutDebugString द्वारा प्रतिस्थापित

utPutDebugString (PChar ("संदेश थ्रेड प्रविष्ट करें" + IntToStr (GetCurrentThreadID)));

रिजल्ट:

डीबग आउटपुट: बटन क्लिक किया गया धागा 5256 प्रक्रिया Project1.exe (1116)
थ्रेड प्रारंभ: थ्रेड ID: 10136। प्रोजेक्ट ProjectNNUMX.exe (1)
डीबग आउटपुट: थ्रेड निष्पादन थ्रेड 10136 प्रक्रिया Project1.exe (1116) दर्ज करें
डीबग आउटपुट: संदेश थ्रेड 5256 दर्ज करें Project1.exe (1116)
डीबग आउटपुट: संदेश थ्रेड 5256 से बाहर निकलें Project1.exe (1116)
डीबग आउटपुट: थ्रेड थ्रेड निष्पादन थ्रेड 10136 प्रक्रिया Project1.exe (1116)
थ्रेड एक्ज़िट: थ्रेड आईडी: 10136. प्रॉजेक्ट Project1.exe (1116)



Alex4445   (2015-12-16 15:02) [22]

OutPutDebugString के साथ पहले पोस्ट की समान विविधता

यूनिट Unit1; इंटरफेस का उपयोग करता है Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls; प्रकार TMyForm = वर्ग (TForm) btn1: TButton; प्रक्रिया btn1Click (प्रेषक: TObject); निजी {निजी घोषणाएँ} जनता {सार्वजनिक घोषणाएँ} प्रक्रिया SyncMsg (var T: TMessage); संदेश WM_USER + 1; समाप्त; TThread1 = वर्ग (TThread) प्रक्रिया निष्पादित; ओवरराइड; समाप्त; वर MyForm: TMyForm; कार्यान्वयन {$ R * .dfm} {} TThread1 प्रक्रिया TThread1.Execute; शुरू FreeOnTerminate: = सत्य; // OutPutDebugString (PCHar ("थ्रेड एक्सक्यूट थ्रेड दर्ज करें" + IntToStr (GetCurrentThreadID))); SendMessage (MyForm.Handle, WM_USER + 1,0,0); // OutPutDebugString (PCHar ("थ्रेड एक्से्यूट थ्रेड" + IntToStr (GetCurrentThreadID))); समाप्त; {} TMyForm प्रक्रिया TMyForm.btn1 क्लिक करें (प्रेषक: TObject); वर ए: इंटेगर; शुरू OutPutDebugString (PChar ("बटन क्लिक थ्रेड" + IntToStr (GetCurrentThreadID))); A के लिए: = 0 से 10 करते हैं TThread1.Create; समाप्त; प्रक्रिया TMyForm.SyncMsg (var T: TMessage); शुरू OutPutDebugString (PCHar ("संदेश थ्रेड दर्ज करें" + IntToStr (GetCurrentThreadID)); नींद (2555); OutPutDebugString (PChar ("संदेश से बाहर निकलें" + IntToStr (GetCurrentThreadID)); समाप्त; समाप्त।

लॉग पहले से ही शुरू में अपेक्षित परिणाम प्रदर्शित करता है: अनुक्रमिक
संदेश दर्ज करें
संदेश से बाहर निकलें
...

डीबग आउटपुट: बटन क्लिक किया गया थ्रेड 3420 प्रक्रिया Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 9960. प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 10132. प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 8228. प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 5324. प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 6312. प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 9732. प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 7696. प्रॉसेस प्रोजेक्ट1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 5240। प्रॉसेस प्रोजेक्ट1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 9692. प्रॉसेस प्रोजेक्ट1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 8916। प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 9544. प्रॉजेक्ट Project1.exe (8140) डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) दर्ज करें डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) से बाहर निकलें डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) दर्ज करें थ्रेड एक्ज़िट: थ्रेड आईडी: 5240. प्रॉजेक्ट Project1.exe (8140) डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) से बाहर निकलें डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) दर्ज करें थ्रेड एक्ज़िट: थ्रेड आईडी: 10132. प्रॉजेक्ट Project1.exe (8140) डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) से बाहर निकलें डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) दर्ज करें थ्रेड एक्ज़िट: थ्रेड आईडी: 9960. प्रॉसेस प्रोजेक्ट1.exe (8140)



Alex4445   (2015-12-16 15:02) [23]

OutPutDebugString के साथ पहले पोस्ट की समान विविधता

यूनिट Unit1; इंटरफेस का उपयोग करता है Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls; प्रकार TMyForm = वर्ग (TForm) btn1: TButton; प्रक्रिया btn1Click (प्रेषक: TObject); निजी {निजी घोषणाएँ} जनता {सार्वजनिक घोषणाएँ} प्रक्रिया SyncMsg (var T: TMessage); संदेश WM_USER + 1; समाप्त; TThread1 = वर्ग (TThread) प्रक्रिया निष्पादित; ओवरराइड; समाप्त; वर MyForm: TMyForm; कार्यान्वयन {$ R * .dfm} {} TThread1 प्रक्रिया TThread1.Execute; शुरू FreeOnTerminate: = सत्य; // OutPutDebugString (PCHar ("थ्रेड एक्सक्यूट थ्रेड दर्ज करें" + IntToStr (GetCurrentThreadID))); SendMessage (MyForm.Handle, WM_USER + 1,0,0); // OutPutDebugString (PCHar ("थ्रेड एक्से्यूट थ्रेड" + IntToStr (GetCurrentThreadID))); समाप्त; {} TMyForm प्रक्रिया TMyForm.btn1 क्लिक करें (प्रेषक: TObject); वर ए: इंटेगर; शुरू OutPutDebugString (PChar ("बटन क्लिक थ्रेड" + IntToStr (GetCurrentThreadID))); A के लिए: = 0 से 10 करते हैं TThread1.Create; समाप्त; प्रक्रिया TMyForm.SyncMsg (var T: TMessage); शुरू OutPutDebugString (PCHar ("संदेश थ्रेड दर्ज करें" + IntToStr (GetCurrentThreadID)); नींद (2555); OutPutDebugString (PChar ("संदेश से बाहर निकलें" + IntToStr (GetCurrentThreadID)); समाप्त; समाप्त।

लॉग पहले से ही शुरू में अपेक्षित परिणाम प्रदर्शित करता है: अनुक्रमिक
संदेश दर्ज करें
संदेश से बाहर निकलें
...

डीबग आउटपुट: बटन क्लिक किया गया थ्रेड 3420 प्रक्रिया Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 9960. प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 10132. प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 8228. प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 5324. प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 6312. प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 9732. प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 7696. प्रॉसेस प्रोजेक्ट1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 5240। प्रॉसेस प्रोजेक्ट1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 9692. प्रॉसेस प्रोजेक्ट1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 8916। प्रॉजेक्ट Project1.exe (8140) थ्रेड प्रारंभ: थ्रेड आईडी: 9544. प्रॉजेक्ट Project1.exe (8140) डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) दर्ज करें डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) से बाहर निकलें डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) दर्ज करें थ्रेड एक्ज़िट: थ्रेड आईडी: 5240. प्रॉजेक्ट Project1.exe (8140) डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) से बाहर निकलें डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) दर्ज करें थ्रेड एक्ज़िट: थ्रेड आईडी: 10132. प्रॉजेक्ट Project1.exe (8140) डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) से बाहर निकलें डीबग आउटपुट: संदेश थ्रेड 3420 प्रक्रिया Project1.exe (8140) दर्ज करें थ्रेड एक्ज़िट: थ्रेड आईडी: 9960. प्रॉसेस प्रोजेक्ट1.exe (8140)



Юрий Зотов ©   (2015-12-16 15:15) [24]

पैनकेक। WinAPI को भूलने लगा। लेकिन अस्पष्ट रूप से याद आया कि SendMessage के विवरण में कुछ कहा गया था। मैंने देखने का फैसला किया - और यह वही है जो मैंने देखा:

यदि निर्दिष्ट विंडो को कॉलिंग थ्रेड द्वारा बनाया गया था, तो विंडो प्रक्रिया को तुरंत सबरूटीन कहा जाता है। यदि निर्दिष्ट विंडो एक अलग थ्रेड द्वारा बनाई गई थी, तो सिस्टम उस धागे पर स्विच करता है और उपयुक्त विंडो प्रक्रिया को कॉल करता है। थ्रेड्स के बीच भेजे गए संदेश केवल तभी संसाधित होते हैं जब प्राप्त थ्रेड संदेश पुनर्प्राप्ति कोड निष्पादित करता है। प्रवेश थ्रेड भेजना अवरुद्ध है जब तक प्राप्त थ्रेड संदेश को संसाधित करता है।

यही है, आप सही हैं - संदेश हैंडलर को मुख्य थ्रेड में निष्पादित किया जाता है। लेकिन यह ज्यादा नहीं बदलता है, क्योंकि परिदृश्य इस तरह हो सकता है:

1. थ्रेड 1 संदेश 1 भेजता है और सिस्टम द्वारा अवरुद्ध है।
2. मुख्य धागा शुरू हुआ (लेकिन अभी तक समाप्त नहीं हुआ है) प्रसंस्करण संदेश 1।
3. थ्रेड 2 संदेश 2 भेजता है और सिस्टम द्वारा अवरुद्ध है।
4. मुख्य सूत्र संसाधित संदेश 2।
5. स्ट्रीम 2 को सिस्टम द्वारा अनलॉक किया गया था और आगे काम करने के लिए चला गया।
6. मुख्य थ्रेड में प्रोसेसिंग संदेश 1 है।
7. स्ट्रीम 1 को सिस्टम द्वारा अनलॉक किया गया था और आगे काम करने के लिए चला गया।

लॉग में, हम देखेंगे:

स्ट्रीम 1 दर्ज करें
स्ट्रीम 2 दर्ज करें
स्ट्रीम 2 को छोड़ दें
स्ट्रीम 1 को छोड़ दें

इसलिए, यदि हम "एन स्ट्रीम करें एन" के तुरंत बाद "स्ट्रीम एन छोड़ दें" देखना चाहते हैं, तो हमें एक महत्वपूर्ण अनुभाग की आवश्यकता है।



sniknik ©   (2015-12-16 15:51) [25]

> आपको एक महत्वपूर्ण अनुभाग की आवश्यकता है।
एक लॉक, दूसरा (स्लीप) करंट को रोक देता है और दूसरों को अनलॉक कर देता है ... परिणामस्वरूप, या तो सभी थ्रेड क्रमिक रूप से एक के रूप में काम करेंगे, पारस्परिक रूप से एक दूसरे से अपेक्षा करते हैं, या, सबसे खराब स्थिति में, आप एक गतिरोध में भाग सकते हैं।

महत्वपूर्ण अनुभाग देखें .... IMHO। पोस्टमेसेज के नियम! :)



Alex4445   (2015-12-16 15:54) [26]


> 1. थ्रेड 1 संदेश 1 भेजता है और सिस्टम द्वारा ब्लॉक किया जाता है।
> 2. मुख्य धागा शुरू हुआ (लेकिन अभी तक समाप्त नहीं हुआ है) संदेश प्रसंस्करण
> 3. थ्रेड 2 संदेश 2 भेजता है और सिस्टम द्वारा ब्लॉक किया जाता है।
> 4. मुख्य सूत्र संसाधित संदेश 2।

तो यह मुझे लगता है, तार्किक रूप से, कि 4 2 छोरों तक नहीं आएगा।
क्योंकि मैसेज प्रोसेसिंग थ्रेड अगले संदेश को तब तक नहीं लेगा, जब तक कि यह पहला खत्म न कर दे।



Юрий Зотов ©   (2015-12-16 17:24) [27]

> स्निकनिक © (16.12.15 15: 51) [25]
> महत्वपूर्ण अनुभाग देखें .... IMHO। पोस्टमेसेज के नियम! :)


यदि हम लॉग प्रविष्टियों के क्रम के प्रति उदासीन नहीं हैं तो मैं सहमत हूं (देखें [१५])।

> एलेक्स 4445 (16.12.15/15/54 26:XNUMX बजे) [XNUMX]
> मैसेज प्रोसेसिंग थ्रेड अगला संदेश नहीं लेगा
> जब तक वह पहला खत्म नहीं कर लेता।


क्यों नहीं? यह बस एक ही विधि का दोहराव है (तथाकथित प्रतिशोध)। यह पुनरावृत्ति की तरह दिखता है, लेकिन इस अंतर के साथ कि विधि को खुद से नहीं बुलाया जाता है, लेकिन बाहर से।



han_malign ©   (2015-12-16 17:42) [28]


> तो यह मुझे लगता है, तार्किक रूप से, कि 4 तब तक नहीं आएगा जब तक यह 2 समाप्त नहीं हो जाता।

- यह सही लगता है ...

अगर कोई भूल गया, D4 में - SynMize SendMessage के माध्यम से काम किया ...

और विंडोज 3. एक्स में दूसरे कार्य पर स्विच करना GetMessage में हुआ, और कुछ मुझे बताता है कि SendMessage का क्रमांकन अभी भी वहाँ हो रहा है ...



sniknik ©   (2015-12-16 17:57) [29]

> अगर हम लॉग प्रविष्टियों के क्रम के प्रति उदासीन नहीं हैं (देखें [१५])।
बस विपरीत ... आदेश "पद" द्वारा गठित कतार के आदेश से होगा, समान प्राथमिकता वाले सभी घटनाओं को कतार के बिना संसाधित किया जाएगा।



Юрий Зотов ©   (2015-12-16 18:40) [30]

> han_malign © (16.12.15 17: 42) [28]
> D4 में - SendMessage के माध्यम से काम किया सिंक्रनाइज़ करें ...

सही। क्या आवेदन के मुख्य धागे के साथ सिंक्रनाइज़ेशन प्रदान किया। लेकिन कुछ अतिरिक्त के बीच नहीं। धाराओं। और विषय उनके बारे में है

1. अपने एक्सक्यूट में थ्रेड 1 को सिंक्रोनाइज़ के माध्यम से मुख्य फॉर्म विधि M कहा जाता है। यह विधि (सुविधा के लिए हम इसे M1 द्वारा निरूपित करते हैं) मुख्य धागे में निष्पादित होने लगती है, लेकिन अभी तक पूरी नहीं हुई है।

2. इस बिंदु पर, अपने Execute में थ्रेड 2 को उसी विधि M का एक ही मुख्य रूप कहा जाता है, और सिंक्रोनाइज़ के माध्यम से भी। यह विधि (सुविधा के लिए हम इसे एम 2 द्वारा निरूपित करते हैं) को भी मुख्य धागे में निष्पादित किया जाएगा

लेकिन जब जब क्या इसे अंजाम दिया जाएगा?

विकल्प 1: मुख्य धागा अस्थायी रूप से एम 1 विधि के निष्पादन को बाधित करेगा (इसकी स्थिति को बनाए रखेगा), फिर एम 2 विधि को निष्पादित करें, फिर एम 1 विधि पर वापस लौटें (मुझे याद है कि एम 1 और एम 2 एक और एक ही मुख्य रूप विधि है, केवल सुविधा के लिए हम निरूपित करते हैं इसकी संख्या भी)।

विकल्प 2: मुख्य धागा पहले विधि एम 1 के निष्पादन को पूरा करेगा, और फिर विधि एम 2 को निष्पादित करेगा।

विकल्प 1 मुझे अधिक वास्तविक लगता है (क्योंकि वास्तव में यह एम 2 सबरूटीन से एम 1 सबरूटीन को कॉल करने के समान है - अर्थात, तंत्र स्वचालित रूप से काम करता है)।



Юрий Зотов ©   (2015-12-16 18:48) [31]

> विकल्प 1 मुझे अधिक वास्तविक लगता है

दरअसल, यदि विकल्प 2 वास्तविक होते, तो कोई विषय नहीं होता।



NoUser ©   (2015-12-17 00:45) [32]

> एलेक्स 4445 (15.12.15/22/37 0:XNUMX बजे) [XNUMX]
10 हर्ट्ज की आवृत्ति के साथ कार्यों को स्थापित करने का क्या मतलब है, अगर उन्हें 0,5 हर्ट्ज की आवृत्ति के साथ किया जाता है?
- जाँच करें कि क्या संदेश कतार के लिए कोई सीमा है?
- हाँ, वह है, जो फिट नहीं है - त्याग दिया जाएगा।

> SendMessage के माध्यम से सिंक्रनाइज़ेशन यदि किसी संदेश संदेश को संसाधित करने के हिस्से के रूप में एक संदेश हैंडलर के अंदर एक परमाणु कार्रवाई की जाती है तो संभव है।



NoUser ©   (2015-12-17 00:58) [33]

ओह, हर्ट्ज के बारे में क्षमा करें,

और प्रश्न का उत्तर "A और B पाइप पर बैठे थे ..." आपका CSL है!



han_malign ©   (2015-12-17 08:43) [34]


> विकल्प 1 मुझे अधिक वास्तविक लगता है

- और फिर भी ठीक है विकल्प 2 केवल सच है ...
निष्पादन अनुक्रम इंटेल और माइक्रोसॉफ्ट द्वारा गारंटी दी गई है ...
एक धागे में केवल एक संदर्भ होता है और एक स्टैक होता है - कुछ और निष्पादित करें (उसकी हालत बचाते हुए) - केवल संदर्भ में एक और धागालेकिन ऐसा नहीं है ...
रेंटेंट सेंडमेसेज - यह काम करता है, लेकिन केवल मुख्य सूत्र के संदर्भ में - और यह एक ईमानदार पुनरावर्तन है, निष्पादन में किसी भी रुकावट की बात नहीं है ...
अगर संभव हो तो देखिये 1 - तो कोई तुल्यकालन आदिम काम नहीं करेगा ...
बेशक वहाँ स्पष्ट setjmp / longjmp के साथ एक विकल्प है - लेकिन यह मामला नहीं है ...

इसलिए विषय सबसे अधिक संभावना है - बस लॉगिंग सिस्टम में (जाहिरा तौर पर अनावश्यक रूप से स्मार्ट बफरिंग के कारण) ... अगर किसी ने नोटिस नहीं किया - अंदर sabzh और दर्ज करें / छोड़ें - सम्मान नहीं ...

Z.Y. मैंने पहले ही इस पर एक से अधिक गतिरोध पकड़ लिए हैं ... वैसे, SendMessage केवल घात नहीं है, पिछली बार जब मैं विज़िबल (उर्फ सेटविंडोवोस, एक अतिरिक्त स्ट्रीम से) था, तो मैं मुख्य धारा में धारावाहिककरण में भाग गया था, जो इस अतिरिक्त द्वारा पकड़े गए एक महत्वपूर्ण खंड की प्रतीक्षा कर रहा था। बहे ...
Z.Z.Y. और TControl.Perform () और SendMessage () को भ्रमित न करें ...



DayGaykin ©   (2015-12-17 10:28) [35]

क्या SendMessage उस थ्रेड पर चल रहा है जिसने इसे कहा है? यहाँ एक खोज है।
और अगर आप इसे बाहरी प्रक्रिया से बुलाते हैं?



Игорь Шевченко ©   (2015-12-17 10:30) [36]


> और अगर आप इसे बाहरी प्रक्रिया से कहते हैं?


और अगर आप रिक्टर पढ़ते हैं? लोकप्रिय लोगों के काम का सम्मान करें।



Alex4445   (2015-12-17 12:50) [37]


> han_malign © (17.12.15 08: 43) [34]
> - और फिर भी यह विकल्प 2 है कि केवल एक ही है
> वफादार ...


मैं सहमत हूं
अप्रत्यक्ष रूप से मैनुअल में पुष्टि मिली
"संसाधन को सिंक्रोनाइज़ करने के विकल्प के रूप में महत्वपूर्ण खंडों या मल्टी-रीड एक्सक्लूसिव-राइट सिंक्रोनाइज़र का उपयोग करके भी संरक्षित किया जा सकता है।"

चर्चा में भाग लेने के लिए आप सभी का धन्यवाद!



Юрий Зотов ©   (2015-12-17 13:21) [38]

> han_malign © (17.12.15 08: 43) [34]
> विकल्प 2 एकमात्र सच है ...


फिर विषय कहां से आया? मैं उद्धृत करता हूं:


> दर्ज करें
> छोड़ दो
> दर्ज करें // ???
> दर्ज करें // ???
> छोड़ दो
> दर्ज करें
> छोड़ दो
> ...

> यह कैसे संभव है?बाद में कैसे किया?
> SendMesssage ने पिछले को पूरा नहीं किया है?


मैं आपको याद दिलाता हूं कि SendMesssage और संदेश हैंडलर दोनों ही मुख्य धागे में दोनों बार निष्पादित होते हैं। और वह दूसरे के समय पहली कॉल की वर्तमान स्थिति को काफी सफलतापूर्वक बचाता है। और दूसरा पूरा करने के बाद, यह राज्य भी सफलतापूर्वक बहाल हो जाता है।

या तो मैं इन तथ्यों की गलत तरीके से व्याख्या करता हूं, या वे आपके बयान से फिट नहीं होते हैं। कृपया उस प्रश्न का उत्तर दें जो मैंने बोल्ड में हाइलाइट किया है।



sniknik ©   (2015-12-17 14:44) [39]

> या तो अपने बयान के साथ वे फिट नहीं हैं
या वाहन ने एक "डिस्यूज़" फेंक दिया, इसका कोड काम नहीं कर रहा है, अर्थात्। हम यह मान सकते हैं कि "यहाँ एक उदाहरण है, लेकिन वास्तव में कोड अलग है।"
[0]
प्रक्रिया TMyThread.Execute; शुरू जबकि (समाप्त नहीं) करते हैं SendMessage (MyForm.Handle, WM_USER + 1,0,0); नींद (100); समाप्त; समाप्त;

या तो असली
Rouse_ © (16.12.15 00: 03) [1]
अधिक संभावना एक लकड़हारा, पहली नज़र में सिंक्रनाइज़ेशन मान्य है

हालांकि "कैसे ???" तब यह स्पष्ट नहीं है
एक उदाहरण दिया
प्रक्रिया TMyThread.Execute; शुरू जबकि (समाप्त नहीं) और (नहीं मास मास) शुरू करते हैं SendMessage (Form1.Handle, WM_USER + 1, GetCurrentThreadId, 0); नींद (यादृच्छिक (100)); समाप्त; समाप्त; प्रक्रिया TForm1.SyncMsg (var संदेश: TMessage); शुरू Memo1.Lines.Add ("Enter" + IntTostr (GetCurrentThreadId) + ":" + IntTostr (Message.WParam)); नींद (100); Memo1.Lines.Add ("छोड़ें" + IntTostr (GetCurrentThreadId) + ":" + IntTostr (संदेश.प्रेम)); समाप्त;
सही क्रम, वास्तविक जोड़े (संदेश। धारा की आईडी) कुछ भी मिश्रण नहीं करते हैं ... हालांकि मैंने यादृच्छिक को जोड़ा और "गलती से" प्रक्रिया को गति देने के लिए कम उम्मीद लगाई।

सामान्य तौर पर, इस दृष्टिकोण के खिलाफ केवल एक चीज बची है
> सभी धागे क्रमिक रूप से एक के रूप में काम करेंगे, पारस्परिक रूप से एक दूसरे से अपेक्षा करते हैं
यहां तक ​​कि इसके लिए महत्वपूर्ण खंड की आवश्यकता नहीं थी।
और आप क्लिक, बटन / बटन सब कुछ से बाहर नहीं निकल सकते।



sniknik ©   (2015-12-17 14:53) [40]

> हालांकि "कैसे ???" तब यह स्पष्ट नहीं है
जब तक CodeSiteLogger में भेजें कुछ समान है - Application.ProcessMessages;



sniknik ©   (2015-12-17 15:01) [41]

!
> जब तक CodeSiteLogger में भेजें कुछ समान है - Application.ProcessMessages;
जाँच की गई -
प्रक्रिया TForm1.SyncMsg (var संदेश: TMessage); शुरू Memo1.Lines.Add ("Enter" + IntTostr (GetCurrentThreadId) + ":" + IntTostr (Message.WParam)); Application.ProcessMessages; नींद (100); Memo1.Lines.Add ("छोड़ें" + IntTostr (GetCurrentThreadId) + ":" + IntTostr (संदेश.प्रेम)); Application.ProcessMessages; समाप्त;
परिणाम (एक टुकड़ा, और इसलिए यह स्पष्ट है, ठीक है, साथ ही "हार्ड हैंग" गायब हो गया (खुद से?), टीएस द्वारा निर्देशित किया जा सकता है, अगर इसका कोड मुख्य धागा लटका नहीं है, तो ऐसा कुछ है ...) -
3904: 3600 दर्ज करें
3904: 6700 दर्ज करें
3904: 6700 छोड़ें
3904: 3600 छोड़ें
3904: 6700 दर्ज करें
3904: 6700 छोड़ें
3904: 6200 छोड़ें
3904: 6700 दर्ज करें
3904: 3600 दर्ज करें
3904: 3600 छोड़ें
3904: 6700 छोड़ें
3904: 3600 दर्ज करें
3904: 3600 छोड़ें
3904: 2636 छोड़ें
3904: 3936 दर्ज करें
3904: 6200 दर्ज करें
3904: 4356 दर्ज करें
3904: 6700 दर्ज करें
3904: 3600 दर्ज करें



Юрий Зотов ©   (2015-12-17 16:18) [42]

पहले 4 पदों पर विचार करें।

1. 3904 दर्ज करें: 3600 - जोड़ें। थ्रेड 3600 SendMessage के माध्यम से संदेश हैंडलर कहा जाता है (यह पहली कॉल है) और मुख्य थ्रेड 3904 ने इस हैंडलर को शुरू किया (लेकिन अभी तक समाप्त नहीं हुआ है)।

2. इस समय जोड़ें 3904: 6700 - दर्ज करें। थ्रेड 6700 SendMessage के माध्यम से भी संदेश हैंडलर कहा जाता है (यह दूसरी कॉल है) और मुख्य धागा 3904 ने इस हैंडलर को शुरू किया।

3. 3904 छोड़ें: 6700 - मुख्य धागे ने सेकंड कॉल को संसाधित किया।

4. 3904 छोड़ें: 3600 - मुख्य सूत्र ने FIRST कॉल को संसाधित किया। और यह काफी सफल है - और इसका मतलब है कि आइटम 2 से पहले संदेश हैंडलर की स्थिति को बचा लिया गया था, और आइटम 3 के बाद - बहाल किया गया था।

===============

अर्थात्, हमारे पास शुद्ध रूप में विकल्प 1 है (देखें [30], [31], [34])। मैं जो बताने की कोशिश कर रहा हूं।



sniknik ©   (2015-12-17 17:35) [43]

परिणामस्वरूप, पहली पोस्ट में Rouse सही था। ;)

और जिस तरह से PostMessage इस मामले में मदद नहीं करता है। ; और अभी भी छोटे "टाइमआउट" के साथ
और स्टैक जल्दी से समाप्त होता है (एक-एक घटना संचालकों को नेस्टेड गुड़िया की तरह घोंसला बनाया जाता है)



Юрий Зотов ©   (2015-12-18 13:26) [44]

IMHO, PostMessage के साथ कोई स्टैक ओवरफ्लो नहीं होना चाहिए। अतिरिक्त। थ्रेड्स केवल मुख्य थ्रेड की कतार में संदेश फेंकते हैं, और मुख्य थ्रेड लाइन लाइन रेक, एक के बाद एक संदेश। यही है, कोई प्रसंस्करण घोंसला नहीं है - इसका मतलब है कि कोई ढेर अतिप्रवाह नहीं है।



sniknik ©   (2015-12-18 14:02) [45]

> स्टैक ओवरफ्लो नहीं होना चाहिए
यदि Application.ProcessMessages के लिए नहीं है; उस पर एक नया प्रसंस्करण चक्र प्रवेश करता है, इसमें अगली कतार संदेश, एक फ़ंक्शन कॉल, आदि को पढ़ता है। आदि। वास्तव में पुनरावृत्ति निकलती है।



पन्ने: 1 2 पूरी शाखा

मंच: "शुरुआती";
वर्तमान संग्रह: 2017.11.12;
डाउनलोड करें: [xml.tar.bz2];

ऊपर





मेमोरी: 0.81 एमबी
समय: 0.043 c
1-1354822431
Pcrepair
2012-12-06 23:33
2017.11.12
फ़ंक्शन के दो संस्करण। क्या चुनना है?


15-1464643802
यूरी
2016-05-31 00:30
2017.11.12
आपको जन्मदिन की शुभकामनाएं! 31 मई 2016 मंगलवार


2-1450384249
मैक्स
2015-12-17 23:30
2017.11.12
स्ट्रिंगराइड को सक्षम बनाएं।


15-1466102639
चर्च
2016-06-16 21:43
2017.11.12
प्रदर्शन मामलों के साथ लैपटॉप


2-1450208244
Alex4445
2015-12-15 22:37
2017.11.12
SendMessage के माध्यम से सिंक करें





अफ्रीकी अल्बानियन अरबी भाषा अर्मेनियाई आज़रबाइजानी बस्क बेलारूसी बल्गेरियाई कैटलन सरलीकृत चीनी) चीनी पारंपरिक) क्रोएशियाई चेक डेनिश डच अंग्रेज़ी एस्तोनियावासी फिलिपिनो फिनिश फ्रेंच
गैलिशियन् जॉर्जियाई जर्मन यूनानी हाईटियन यहूदी हिंदी हंगरी आइसलैंड का इन्डोनेशियाई आयरिश इतालवी जापानी कोरियाई लात्वीयावासी लिथुआनियाई मेसीडोनियन मलायी मोलतिज़ नार्वेजियन
फ़ारसी पोलिश पुर्तगाली रोमानियाई रूसी सर्बियाई स्लोवाक स्लोवेनियाई स्पेनिश स्वाहिली स्वीडिश थाई तुर्की यूक्रेनी उर्दू वियतनामी वेल्श यहूदी बंगाली बोस्नियाई
सिबुआनो एस्पेरांतो गुजराती हौसा हमोंग ईग्बो जावानीस कन्नड़ खमेर लाओ लैटिन माओरी मराठी मंगोलियन नेपाली पंजाबी सोमाली तामिल तेलुगु योरूबा
ज़ुलु
Английский Французский Немецкий Итальянский Португальский Русский Испанский