.NET: ਮਲਟੀਥ੍ਰੈਡਿੰਗ ਅਤੇ ਅਸਿੰਕ੍ਰੋਨੀ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਟੂਲ। ਭਾਗ 1

ਮੈਂ ਹਬਰ 'ਤੇ ਮੂਲ ਲੇਖ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਰਿਹਾ ਹਾਂ, ਜਿਸਦਾ ਅਨੁਵਾਦ ਕਾਰਪੋਰੇਟ ਵਿੱਚ ਪੋਸਟ ਕੀਤਾ ਗਿਆ ਹੈ ਬਲਾੱਗ ਪੋਸਟ.

ਇੱਥੇ ਅਤੇ ਹੁਣ ਨਤੀਜੇ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ, ਅਸਿੰਕਰੋਨਸ ਤੌਰ 'ਤੇ ਕੁਝ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ, ਜਾਂ ਇਸ ਨੂੰ ਕਰਨ ਵਾਲੀਆਂ ਕਈ ਇਕਾਈਆਂ ਵਿਚਕਾਰ ਵੱਡੇ ਕੰਮ ਨੂੰ ਵੰਡਣ ਦੀ ਜ਼ਰੂਰਤ, ਕੰਪਿਊਟਰਾਂ ਦੇ ਆਗਮਨ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦ ਸੀ। ਉਨ੍ਹਾਂ ਦੇ ਆਗਮਨ ਨਾਲ ਇਹ ਲੋੜ ਬਹੁਤ ਹੀ ਠੋਸ ਹੋ ਗਈ। ਹੁਣ, 2019 ਵਿੱਚ, ਮੈਂ ਇਸ ਲੇਖ ਨੂੰ 8-ਕੋਰ ਇੰਟੇਲ ਕੋਰ ਪ੍ਰੋਸੈਸਰ ਵਾਲੇ ਲੈਪਟਾਪ 'ਤੇ ਟਾਈਪ ਕਰ ਰਿਹਾ ਹਾਂ, ਜਿਸ 'ਤੇ ਸੌ ਤੋਂ ਵੱਧ ਪ੍ਰਕਿਰਿਆਵਾਂ ਸਮਾਨਾਂਤਰ ਚੱਲ ਰਹੀਆਂ ਹਨ, ਅਤੇ ਹੋਰ ਵੀ ਥ੍ਰੈੱਡਸ। ਨੇੜੇ, ਇੱਕ ਥੋੜਾ ਜਿਹਾ ਖਰਾਬ ਫੋਨ ਹੈ, ਜੋ ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ ਖਰੀਦਿਆ ਗਿਆ ਸੀ, ਇਸ ਵਿੱਚ ਬੋਰਡ 'ਤੇ 8-ਕੋਰ ਪ੍ਰੋਸੈਸਰ ਹੈ। ਥੀਮੈਟਿਕ ਸਰੋਤ ਲੇਖਾਂ ਅਤੇ ਵੀਡੀਓ ਨਾਲ ਭਰੇ ਹੋਏ ਹਨ ਜਿੱਥੇ ਉਹਨਾਂ ਦੇ ਲੇਖਕ ਇਸ ਸਾਲ ਦੇ ਫਲੈਗਸ਼ਿਪ ਸਮਾਰਟਫ਼ੋਨਾਂ ਦੀ ਪ੍ਰਸ਼ੰਸਾ ਕਰਦੇ ਹਨ ਜੋ 16-ਕੋਰ ਪ੍ਰੋਸੈਸਰਾਂ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਰੱਖਦੇ ਹਨ। MS Azure ਇੱਕ 20 ਕੋਰ ਪ੍ਰੋਸੈਸਰ ਅਤੇ 128 TB RAM ਵਾਲੀ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ $2/ਘੰਟੇ ਤੋਂ ਘੱਟ ਵਿੱਚ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਥਰਿੱਡਾਂ ਦੇ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਤੋਂ ਬਿਨਾਂ ਇਸ ਸ਼ਕਤੀ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਕੱਢਣਾ ਅਤੇ ਇਸ ਸ਼ਕਤੀ ਨੂੰ ਵਰਤਣਾ ਅਸੰਭਵ ਹੈ।

ਪਰਿਭਾਸ਼ਾ

ਪ੍ਰਕਿਰਿਆ - OS ਆਬਜੈਕਟ, ਆਈਸੋਲੇਟਿਡ ਐਡਰੈੱਸ ਸਪੇਸ, ਥਰਿੱਡਸ ਰੱਖਦਾ ਹੈ।
ਥਰਿੱਡ - ਇੱਕ OS ਆਬਜੈਕਟ, ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੀ ਸਭ ਤੋਂ ਛੋਟੀ ਇਕਾਈ, ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹਿੱਸਾ, ਥ੍ਰੈੱਡ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅੰਦਰ ਆਪਸ ਵਿੱਚ ਮੈਮੋਰੀ ਅਤੇ ਹੋਰ ਸਰੋਤ ਸਾਂਝੇ ਕਰਦੇ ਹਨ।
ਮਨੌਗੋਜ਼ਾਦਾਚਨੋਸਤੀ - OS ਸੰਪਤੀ, ਕਈ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਚਲਾਉਣ ਦੀ ਯੋਗਤਾ
ਮਲਟੀ-ਕੋਰ - ਪ੍ਰੋਸੈਸਰ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ, ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਕਈ ਕੋਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਗਤਾ
ਮਲਟੀਪ੍ਰੋਸੈਸਿੰਗ - ਇੱਕ ਕੰਪਿਊਟਰ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ, ਕਈ ਪ੍ਰੋਸੈਸਰਾਂ ਨਾਲ ਇੱਕੋ ਸਮੇਂ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਯੋਗਤਾ
ਮਲਟੀਥ੍ਰੈਡਿੰਗ - ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ, ਕਈ ਥ੍ਰੈਡਾਂ ਵਿੱਚ ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਵੰਡਣ ਦੀ ਯੋਗਤਾ।
ਸਮਾਨਤਾ - ਸਮੇਂ ਦੀ ਪ੍ਰਤੀ ਯੂਨਿਟ ਦੇ ਨਾਲ ਕਈ ਕਿਰਿਆਵਾਂ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਕਰਨਾ
ਅਸਿੰਕ੍ਰੋਨੀ - ਇਸ ਪ੍ਰੋਸੈਸਿੰਗ ਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਕਿਸੇ ਓਪਰੇਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨਾ; ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੇ ਨਤੀਜੇ 'ਤੇ ਬਾਅਦ ਵਿੱਚ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਰੂਪਕ

ਸਾਰੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਚੰਗੀਆਂ ਨਹੀਂ ਹਨ ਅਤੇ ਕੁਝ ਨੂੰ ਵਾਧੂ ਵਿਆਖਿਆ ਦੀ ਲੋੜ ਹੈ, ਇਸਲਈ ਮੈਂ ਰਸਮੀ ਤੌਰ 'ਤੇ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ ਨਾਸ਼ਤਾ ਪਕਾਉਣ ਬਾਰੇ ਇੱਕ ਰੂਪਕ ਸ਼ਾਮਲ ਕਰਾਂਗਾ। ਇਸ ਅਲੰਕਾਰ ਵਿੱਚ ਨਾਸ਼ਤਾ ਪਕਾਉਣਾ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਹੈ।

ਸਵੇਰੇ ਨਾਸ਼ਤਾ ਤਿਆਰ ਕਰਦੇ ਸਮੇਂ ਮੈਂ (CPU) ਮੈਂ ਰਸੋਈ ਵਿੱਚ ਆਉਂਦਾ ਹਾਂ (ਕੰਪਿਊਟਰ). ਮੇਰੇ ਕੋਲ 2 ਹੱਥ ਹਨ (ਕੋਰ). ਰਸੋਈ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਉਪਕਰਣ ਹਨ (IO): ਓਵਨ, ਕੇਤਲੀ, ਟੋਸਟਰ, ਫਰਿੱਜ। ਮੈਂ ਗੈਸ ਚਾਲੂ ਕਰਦਾ ਹਾਂ, ਇਸ 'ਤੇ ਇੱਕ ਤਲ਼ਣ ਵਾਲਾ ਪੈਨ ਰੱਖਦਾ ਹਾਂ ਅਤੇ ਇਸ ਦੇ ਗਰਮ ਹੋਣ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਇਸ ਵਿੱਚ ਤੇਲ ਪਾ ਦਿੰਦਾ ਹਾਂ (ਅਸਿੰਕ੍ਰੋਨਸਲੀ, ਗੈਰ-ਬਲਾਕਿੰਗ-IO-ਉਡੀਕ), ਮੈਂ ਫਰਿੱਜ ਵਿੱਚੋਂ ਅੰਡੇ ਕੱਢਦਾ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਪਲੇਟ ਵਿੱਚ ਤੋੜਦਾ ਹਾਂ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਹੱਥ ਨਾਲ ਕੁੱਟਦਾ ਹਾਂ (ਥ੍ਰੈੱਡ#1), ਅਤੇ ਦੂਜਾ (ਥ੍ਰੈੱਡ#2) ਪਲੇਟ ਨੂੰ ਫੜਨਾ (ਸਾਂਝਾ ਸਰੋਤ)। ਹੁਣ ਮੈਂ ਕੇਤਲੀ ਨੂੰ ਚਾਲੂ ਕਰਨਾ ਚਾਹਾਂਗਾ, ਪਰ ਮੇਰੇ ਕੋਲ ਲੋੜੀਂਦੇ ਹੱਥ ਨਹੀਂ ਹਨ (ਥ੍ਰੈਡ ਭੁੱਖਮਰੀ) ਇਸ ਸਮੇਂ ਦੇ ਦੌਰਾਨ, ਤਲ਼ਣ ਵਾਲਾ ਪੈਨ ਗਰਮ ਹੋ ਜਾਂਦਾ ਹੈ (ਨਤੀਜੇ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨਾ) ਜਿਸ ਵਿੱਚ ਮੈਂ ਜੋ ਮੈਂ ਕੋਰੜੇ ਮਾਰਿਆ ਹੈ ਡੋਲ੍ਹਦਾ ਹਾਂ। ਮੈਂ ਕੇਤਲੀ ਤੱਕ ਪਹੁੰਚਦਾ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਚਾਲੂ ਕਰਦਾ ਹਾਂ ਅਤੇ ਮੂਰਖਤਾ ਨਾਲ ਇਸ ਵਿੱਚ ਪਾਣੀ ਨੂੰ ਉਬਲਦਾ ਦੇਖਦਾ ਹਾਂ (ਬਲਾਕਿੰਗ-IO-ਉਡੀਕ ਕਰੋ), ਹਾਲਾਂਕਿ ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਉਹ ਪਲੇਟ ਨੂੰ ਧੋ ਸਕਦਾ ਸੀ ਜਿੱਥੇ ਉਸਨੇ ਆਮਲੇਟ ਨੂੰ ਕੋਰੜੇ ਮਾਰਿਆ ਸੀ।

ਮੈਂ ਸਿਰਫ 2 ਹੱਥਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਆਮਲੇਟ ਪਕਾਇਆ, ਅਤੇ ਮੇਰੇ ਕੋਲ ਹੋਰ ਨਹੀਂ ਹੈ, ਪਰ ਉਸੇ ਸਮੇਂ, ਆਮਲੇਟ ਨੂੰ ਕੋਰੜੇ ਮਾਰਨ ਦੇ ਸਮੇਂ, 3 ਓਪਰੇਸ਼ਨ ਇੱਕੋ ਸਮੇਂ ਹੋਏ: ਆਮਲੇਟ ਨੂੰ ਕੋਰੜੇ ਮਾਰਨਾ, ਪਲੇਟ ਨੂੰ ਫੜਨਾ, ਤਲ਼ਣ ਵਾਲੇ ਪੈਨ ਨੂੰ ਗਰਮ ਕਰਨਾ CPU ਕੰਪਿਊਟਰ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਹਿੱਸਾ ਹੈ, IO ਉਹ ਹੁੰਦਾ ਹੈ ਜੋ ਅਕਸਰ ਸਭ ਕੁਝ ਹੌਲੀ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਸਲਈ ਅਕਸਰ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੱਲ ਇਹ ਹੈ ਕਿ IO ਤੋਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਸਮੇਂ CPU ਨੂੰ ਕਿਸੇ ਚੀਜ਼ ਨਾਲ ਕਬਜੇ ਵਿੱਚ ਲਿਆ ਜਾਵੇ।

ਅਲੰਕਾਰ ਨੂੰ ਜਾਰੀ ਰੱਖਣਾ:

• ਜੇਕਰ ਆਮਲੇਟ ਤਿਆਰ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ, ਮੈਂ ਕੱਪੜੇ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ, ਤਾਂ ਇਹ ਮਲਟੀਟਾਸਕਿੰਗ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਹੋਵੇਗੀ। ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸੂਚਕ: ਕੰਪਿਊਟਰ ਇਸ ਵਿੱਚ ਲੋਕਾਂ ਨਾਲੋਂ ਬਹੁਤ ਵਧੀਆ ਹਨ.
• ਕਈ ਸ਼ੈੱਫਾਂ ਵਾਲੀ ਇੱਕ ਰਸੋਈ, ਉਦਾਹਰਨ ਲਈ ਇੱਕ ਰੈਸਟੋਰੈਂਟ ਵਿੱਚ - ਇੱਕ ਮਲਟੀ-ਕੋਰ ਕੰਪਿਊਟਰ।
• ਇੱਕ ਸ਼ਾਪਿੰਗ ਸੈਂਟਰ ਵਿੱਚ ਫੂਡ ਕੋਰਟ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਰੈਸਟੋਰੈਂਟ - ਡੇਟਾ ਸੈਂਟਰ

.NET ਟੂਲਜ਼

.NET ਥਰਿੱਡਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਵਿੱਚ ਵਧੀਆ ਹੈ, ਜਿਵੇਂ ਕਿ ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਨਾਲ। ਹਰੇਕ ਨਵੇਂ ਸੰਸਕਰਣ ਦੇ ਨਾਲ, ਇਹ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਨਵੇਂ ਟੂਲ ਪੇਸ਼ ਕਰਦਾ ਹੈ, OS ਥਰਿੱਡਾਂ ਉੱਤੇ ਐਬਸਟਰੈਕਸ਼ਨ ਦੀਆਂ ਨਵੀਆਂ ਪਰਤਾਂ। ਐਬਸਟਰੈਕਸ਼ਨ ਦੇ ਨਿਰਮਾਣ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਫਰੇਮਵਰਕ ਡਿਵੈਲਪਰ ਇੱਕ ਅਜਿਹੀ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਜੋ ਮੌਕਾ ਛੱਡਦਾ ਹੈ, ਜਦੋਂ ਉੱਚ-ਪੱਧਰੀ ਐਬਸਟਰੈਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਪੱਧਰਾਂ ਤੋਂ ਹੇਠਾਂ ਜਾਣ ਲਈ। ਬਹੁਤੇ ਅਕਸਰ ਇਹ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੁੰਦਾ, ਅਸਲ ਵਿੱਚ ਇਹ ਇੱਕ ਸ਼ਾਟਗਨ ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਪੈਰਾਂ ਵਿੱਚ ਗੋਲੀ ਮਾਰਨ ਦਾ ਦਰਵਾਜ਼ਾ ਖੋਲ੍ਹਦਾ ਹੈ, ਪਰ ਕਈ ਵਾਰ, ਦੁਰਲੱਭ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇਹ ਇੱਕ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਅਮੂਰਤਤਾ ਦੇ ਮੌਜੂਦਾ ਪੱਧਰ 'ਤੇ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ. .

ਟੂਲਸ ਦੁਆਰਾ, ਮੇਰਾ ਮਤਲਬ ਫਰੇਮਵਰਕ ਅਤੇ ਥਰਡ-ਪਾਰਟੀ ਪੈਕੇਜਾਂ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਇੰਟਰਫੇਸ (APIs) ਦੇ ਨਾਲ ਨਾਲ ਪੂਰੇ ਸਾਫਟਵੇਅਰ ਹੱਲ ਹਨ ਜੋ ਮਲਟੀ-ਥ੍ਰੈਡਡ ਕੋਡ ਨਾਲ ਸਬੰਧਤ ਕਿਸੇ ਵੀ ਸਮੱਸਿਆ ਲਈ ਖੋਜ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦੇ ਹਨ।

ਇੱਕ ਥਰਿੱਡ ਸ਼ੁਰੂ ਕਰ ਰਿਹਾ ਹੈ

ਥ੍ਰੈਡ ਕਲਾਸ ਥ੍ਰੈਡਸ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ .NET ਵਿੱਚ ਸਭ ਤੋਂ ਬੁਨਿਆਦੀ ਕਲਾਸ ਹੈ। ਕੰਸਟਰਕਟਰ ਦੋ ਡੈਲੀਗੇਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ:

• ਥ੍ਰੈਡਸਟਾਰਟ - ਕੋਈ ਪੈਰਾਮੀਟਰ ਨਹੀਂ
• ParametrizedThreadStart - ਕਿਸਮ ਦੇ ਵਸਤੂ ਦੇ ਇੱਕ ਪੈਰਾਮੀਟਰ ਨਾਲ।

ਸਟਾਰਟ ਵਿਧੀ ਨੂੰ ਕਾਲ ਕਰਨ ਤੋਂ ਬਾਅਦ ਡੈਲੀਗੇਟ ਨੂੰ ਨਵੇਂ ਬਣਾਏ ਥ੍ਰੈਡ ਵਿੱਚ ਚਲਾਇਆ ਜਾਵੇਗਾ। ਜੇਕਰ ਕਿਸਮ ਦਾ ਇੱਕ ਡੈਲੀਗੇਟ ParametrizedThreadStart ਕੰਸਟਰਕਟਰ ਨੂੰ ਪਾਸ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਇੱਕ ਵਸਤੂ ਨੂੰ ਸਟਾਰਟ ਵਿਧੀ ਵਿੱਚ ਪਾਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਸਥਾਨਕ ਜਾਣਕਾਰੀ ਨੂੰ ਸਟ੍ਰੀਮ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਲਈ ਇਸ ਵਿਧੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਥਰਿੱਡ ਬਣਾਉਣਾ ਇੱਕ ਮਹਿੰਗਾ ਓਪਰੇਸ਼ਨ ਹੈ, ਅਤੇ ਥਰਿੱਡ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਭਾਰੀ ਵਸਤੂ ਹੈ, ਘੱਟੋ ਘੱਟ ਕਿਉਂਕਿ ਇਹ ਸਟੈਕ 'ਤੇ 1MB ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਅਤੇ OS API ਨਾਲ ਗੱਲਬਾਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

new Thread(...).Start(...);

ਥ੍ਰੈਡਪੂਲ ਕਲਾਸ ਪੂਲ ਦੀ ਧਾਰਨਾ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ। .NET ਵਿੱਚ, ਥ੍ਰੈਡ ਪੂਲ ਇੰਜਨੀਅਰਿੰਗ ਦਾ ਇੱਕ ਹਿੱਸਾ ਹੈ, ਅਤੇ Microsoft ਦੇ ਡਿਵੈਲਪਰਾਂ ਨੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਬਹੁਤ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੈ ਕਿ ਇਹ ਵਿਭਿੰਨ ਕਿਸਮਾਂ ਦੇ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਵਧੀਆ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ।

ਆਮ ਧਾਰਨਾ:

ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਦੇ ਸਮੇਂ ਤੋਂ, ਇਹ ਬੈਕਗ੍ਰਾਉਂਡ ਵਿੱਚ ਰਿਜ਼ਰਵ ਵਿੱਚ ਕਈ ਥ੍ਰੈੱਡ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵਰਤੋਂ ਲਈ ਲੈ ਜਾਣ ਦੀ ਸਮਰੱਥਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਥਰਿੱਡਾਂ ਨੂੰ ਅਕਸਰ ਅਤੇ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਪੂਲ ਕਾਲਰ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਫੈਲਦਾ ਹੈ। ਜਦੋਂ ਸਹੀ ਸਮੇਂ 'ਤੇ ਪੂਲ ਵਿੱਚ ਕੋਈ ਖਾਲੀ ਥ੍ਰੈੱਡ ਨਹੀਂ ਹੁੰਦੇ, ਤਾਂ ਇਹ ਜਾਂ ਤਾਂ ਥਰਿੱਡਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੇ ਵਾਪਸ ਆਉਣ ਦੀ ਉਡੀਕ ਕਰੇਗਾ, ਜਾਂ ਇੱਕ ਨਵਾਂ ਬਣਾਵੇਗਾ। ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੈ ਕਿ ਥ੍ਰੈੱਡ ਪੂਲ ਕੁਝ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹੈ ਅਤੇ ਉਹਨਾਂ ਕਾਰਜਾਂ ਲਈ ਮਾੜਾ ਅਨੁਕੂਲ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਪੂਰੇ ਓਪਰੇਸ਼ਨ ਦੌਰਾਨ ਸੇਵਾਵਾਂ ਵਜੋਂ ਚੱਲਦੇ ਹਨ।

ਪੂਲ ਤੋਂ ਇੱਕ ਥਰਿੱਡ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ, ਇੱਕ QueueUserWorkItem ਵਿਧੀ ਹੈ ਜੋ WaitCallback ਕਿਸਮ ਦੇ ਇੱਕ ਡੈਲੀਗੇਟ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ParametrizedThreadStart ਦੇ ਸਮਾਨ ਦਸਤਖਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਸ ਨੂੰ ਪਾਸ ਕੀਤਾ ਗਿਆ ਪੈਰਾਮੀਟਰ ਉਹੀ ਫੰਕਸ਼ਨ ਕਰਦਾ ਹੈ।

ThreadPool.QueueUserWorkItem(...);

ਘੱਟ-ਜਾਣਿਆ ਥਰਿੱਡ ਪੂਲ ਵਿਧੀ RegisterWaitForSingleObject ਨੂੰ ਗੈਰ-ਬਲਾਕਿੰਗ IO ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿਧੀ ਨੂੰ ਪਾਸ ਕੀਤੇ ਗਏ ਡੈਲੀਗੇਟ ਨੂੰ ਉਦੋਂ ਬੁਲਾਇਆ ਜਾਵੇਗਾ ਜਦੋਂ ਵਿਧੀ ਨੂੰ ਪਾਸ ਕੀਤਾ ਵੇਟਹੈਂਡਲ "ਰਿਲੀਜ਼" ਹੋਵੇ।

ThreadPool.RegisterWaitForSingleObject(...)

.NET ਦਾ ਇੱਕ ਥ੍ਰੈਡ ਟਾਈਮਰ ਹੈ ਅਤੇ ਇਹ WinForms/WPF ਟਾਈਮਰ ਤੋਂ ਵੱਖਰਾ ਹੈ ਕਿ ਇਸਦੇ ਹੈਂਡਲਰ ਨੂੰ ਪੂਲ ਤੋਂ ਲਏ ਗਏ ਥ੍ਰੈਡ 'ਤੇ ਬੁਲਾਇਆ ਜਾਵੇਗਾ।

System.Threading.Timer

ਪੂਲ ਤੋਂ ਥਰਿੱਡ 'ਤੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਲਈ ਡੈਲੀਗੇਟ ਨੂੰ ਭੇਜਣ ਦਾ ਇੱਕ ਅਨੋਖਾ ਤਰੀਕਾ ਵੀ ਹੈ - BeginInvoke ਵਿਧੀ।

DelegateInstance.BeginInvoke

ਮੈਂ ਸੰਖੇਪ ਵਿੱਚ ਉਸ ਫੰਕਸ਼ਨ 'ਤੇ ਧਿਆਨ ਦੇਣਾ ਚਾਹਾਂਗਾ ਜਿਸ ਲਈ ਉਪਰੋਕਤ ਕਈ ਵਿਧੀਆਂ ਨੂੰ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ - Kernel32.dll Win32 API ਤੋਂ CreateThread। ਇਸ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ, ਬਾਹਰੀ ਤਰੀਕਿਆਂ ਦੀ ਵਿਧੀ ਦਾ ਧੰਨਵਾਦ. ਮੈਂ ਵਿਰਾਸਤੀ ਕੋਡ ਦੀ ਇੱਕ ਭਿਆਨਕ ਉਦਾਹਰਣ ਵਿੱਚ ਸਿਰਫ ਇੱਕ ਵਾਰ ਅਜਿਹੀ ਕਾਲ ਦੇਖੀ ਹੈ, ਅਤੇ ਲੇਖਕ ਦੀ ਪ੍ਰੇਰਣਾ ਜਿਸਨੇ ਬਿਲਕੁਲ ਅਜਿਹਾ ਕੀਤਾ ਸੀ, ਮੇਰੇ ਲਈ ਅਜੇ ਵੀ ਇੱਕ ਰਹੱਸ ਬਣਿਆ ਹੋਇਆ ਹੈ.

Kernel32.dll CreateThread

ਥਰਿੱਡਾਂ ਨੂੰ ਦੇਖਣਾ ਅਤੇ ਡੀਬੱਗ ਕਰਨਾ

ਤੁਹਾਡੇ ਦੁਆਰਾ ਬਣਾਏ ਗਏ ਥ੍ਰੈੱਡਸ, ਸਾਰੇ ਥਰਡ-ਪਾਰਟੀ ਕੰਪੋਨੈਂਟਸ, ਅਤੇ .NET ਪੂਲ ਨੂੰ ਵਿਜ਼ੂਅਲ ਸਟੂਡੀਓ ਦੀ ਥ੍ਰੈਡ ਵਿੰਡੋ ਵਿੱਚ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਵਿੰਡੋ ਸਿਰਫ ਥ੍ਰੈਡ ਜਾਣਕਾਰੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰੇਗੀ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਡੀਬੱਗ ਦੇ ਅਧੀਨ ਹੈ ਅਤੇ ਬ੍ਰੇਕ ਮੋਡ ਵਿੱਚ ਹੈ। ਇੱਥੇ ਤੁਸੀਂ ਹਰੇਕ ਥ੍ਰੈਡ ਦੇ ਸਟੈਕ ਨਾਮ ਅਤੇ ਤਰਜੀਹਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਦੇਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਡੀਬੱਗਿੰਗ ਨੂੰ ਇੱਕ ਖਾਸ ਥ੍ਰੈਡ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ। ਥ੍ਰੈਡ ਕਲਾਸ ਦੀ ਪ੍ਰਾਥਮਿਕਤਾ ਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਤੁਸੀਂ ਇੱਕ ਥ੍ਰੈੱਡ ਦੀ ਤਰਜੀਹ ਸੈਟ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਸ ਨੂੰ OC ਅਤੇ CLR ਇੱਕ ਸਿਫਾਰਿਸ਼ ਵਜੋਂ ਸਮਝਣਗੇ ਜਦੋਂ ਥ੍ਰੈੱਡਾਂ ਵਿਚਕਾਰ ਪ੍ਰੋਸੈਸਰ ਸਮਾਂ ਵੰਡਦੇ ਹਨ।

ਕੰਮ ਪੈਰਲਲ ਲਾਇਬ੍ਰੇਰੀ

ਟਾਸਕ ਪੈਰਲਲ ਲਾਇਬ੍ਰੇਰੀ (TPL) ਨੂੰ .NET 4.0 ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ। ਹੁਣ ਇਹ ਅਸਿੰਕ੍ਰੋਨੀ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਮਿਆਰੀ ਅਤੇ ਮੁੱਖ ਸਾਧਨ ਹੈ। ਕੋਈ ਵੀ ਕੋਡ ਜੋ ਪੁਰਾਣੀ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਉਸਨੂੰ ਵਿਰਾਸਤ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। TPL ਦੀ ਮੂਲ ਇਕਾਈ System.Threading.Tasks ਨੇਮਸਪੇਸ ਤੋਂ ਟਾਸਕ ਕਲਾਸ ਹੈ। ਇੱਕ ਕੰਮ ਇੱਕ ਧਾਗੇ ਉੱਤੇ ਇੱਕ ਐਬਸਟਰੈਕਸ਼ਨ ਹੁੰਦਾ ਹੈ। C# ਭਾਸ਼ਾ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣ ਦੇ ਨਾਲ, ਸਾਨੂੰ Tasks - async/await operators ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਇੱਕ ਸ਼ਾਨਦਾਰ ਤਰੀਕਾ ਮਿਲਿਆ ਹੈ। ਇਹਨਾਂ ਸੰਕਲਪਾਂ ਨੇ ਅਸਿੰਕ੍ਰੋਨਸ ਕੋਡ ਨੂੰ ਲਿਖਣਾ ਸੰਭਵ ਬਣਾਇਆ ਜਿਵੇਂ ਕਿ ਇਹ ਸਧਾਰਨ ਅਤੇ ਸਮਕਾਲੀ ਸੀ, ਇਸ ਨਾਲ ਥਰਿੱਡਾਂ ਦੇ ਅੰਦਰੂਨੀ ਕੰਮਕਾਜ ਦੀ ਥੋੜੀ ਸਮਝ ਵਾਲੇ ਲੋਕਾਂ ਲਈ ਉਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲਿਖਣਾ ਸੰਭਵ ਹੋ ਜਾਂਦਾ ਹੈ ਜੋ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਐਪਲੀਕੇਸ਼ਨ ਜੋ ਲੰਬੇ ਓਪਰੇਸ਼ਨ ਕਰਨ ਵੇਲੇ ਫ੍ਰੀਜ਼ ਨਹੀਂ ਹੁੰਦੀਆਂ ਹਨ। async/await ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਇੱਕ ਜਾਂ ਕਈ ਲੇਖਾਂ ਲਈ ਇੱਕ ਵਿਸ਼ਾ ਹੈ, ਪਰ ਮੈਂ ਕੁਝ ਵਾਕਾਂ ਵਿੱਚ ਇਸਦਾ ਸਾਰ ਲੈਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ:

• async ਟਾਸਕ ਜਾਂ ਵਾਇਡ ਵਾਪਸ ਕਰਨ ਵਾਲੀ ਵਿਧੀ ਦਾ ਇੱਕ ਸੋਧਕ ਹੈ
• ਅਤੇ ਉਡੀਕ ਇੱਕ ਨਾਨ-ਬਲਾਕਿੰਗ ਟਾਸਕ ਵੇਟਿੰਗ ਆਪਰੇਟਰ ਹੈ।

ਇੱਕ ਵਾਰ ਫਿਰ: ਉਡੀਕ ਓਪਰੇਟਰ, ਆਮ ਸਥਿਤੀ ਵਿੱਚ (ਇੱਥੇ ਅਪਵਾਦ ਹਨ), ਮੌਜੂਦਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੇ ਥ੍ਰੈਡ ਨੂੰ ਅੱਗੇ ਜਾਰੀ ਕਰੇਗਾ, ਅਤੇ ਜਦੋਂ ਟਾਸਕ ਆਪਣਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪੂਰਾ ਕਰ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਥ੍ਰੈਡ (ਅਸਲ ਵਿੱਚ, ਸੰਦਰਭ ਕਹਿਣਾ ਵਧੇਰੇ ਸਹੀ ਹੋਵੇਗਾ। , ਪਰ ਬਾਅਦ ਵਿੱਚ ਇਸ ਬਾਰੇ ਹੋਰ) ਵਿਧੀ ਨੂੰ ਅੱਗੇ ਚਲਾਉਣਾ ਜਾਰੀ ਰੱਖੇਗਾ। .NET ਦੇ ਅੰਦਰ, ਇਹ ਵਿਧੀ ਉਸੇ ਤਰ੍ਹਾਂ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਿਵੇਂ ਕਿ ਉਪਜ ਵਾਪਸੀ, ਜਦੋਂ ਲਿਖਤੀ ਵਿਧੀ ਇੱਕ ਪੂਰੀ ਕਲਾਸ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਰਾਜ ਮਸ਼ੀਨ ਹੈ ਅਤੇ ਇਹਨਾਂ ਰਾਜਾਂ ਦੇ ਅਧਾਰ ਤੇ ਵੱਖਰੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਕੋਈ ਵੀ ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲਾ ਕੋਈ ਵੀ ਸਧਾਰਨ ਕੋਡ asynс/await ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਿਖ ਸਕਦਾ ਹੈ, ਕੰਪਾਈਲਰ ਜਨਰੇਟਡ ਕੋਡ ਸਮਰੱਥ ਦੇ ਨਾਲ JetBrains dotPeek ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਸੈਂਬਲੀ ਨੂੰ ਕੰਪਾਇਲ ਅਤੇ ਦੇਖ ਸਕਦਾ ਹੈ।

ਆਉ ਟਾਸਕ ਨੂੰ ਲਾਂਚ ਕਰਨ ਅਤੇ ਵਰਤਣ ਲਈ ਵਿਕਲਪਾਂ ਨੂੰ ਵੇਖੀਏ। ਹੇਠਾਂ ਦਿੱਤੀ ਕੋਡ ਉਦਾਹਰਨ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਨਵਾਂ ਕੰਮ ਬਣਾਉਂਦੇ ਹਾਂ ਜੋ ਕੁਝ ਵੀ ਲਾਭਦਾਇਕ ਨਹੀਂ ਹੁੰਦਾ (ਥ੍ਰੈਡ.ਸਲੀਪ(10000)), ਪਰ ਅਸਲ ਜੀਵਨ ਵਿੱਚ ਇਹ ਕੁਝ ਗੁੰਝਲਦਾਰ CPU-ਇੰਟੈਂਸਿਵ ਕੰਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

using TCO = System.Threading.Tasks.TaskCreationOptions;

public static async void VoidAsyncMethod() {
    var cancellationSource = new CancellationTokenSource();

    await Task.Factory.StartNew(
        // Code of action will be executed on other context
        () => Thread.Sleep(10000),
        cancellationSource.Token,
        TCO.LongRunning | TCO.AttachedToParent | TCO.PreferFairness,
        scheduler
    );

    //  Code after await will be executed on captured context
}

ਇੱਕ ਕਾਰਜ ਨੂੰ ਕਈ ਵਿਕਲਪਾਂ ਨਾਲ ਬਣਾਇਆ ਗਿਆ ਹੈ:

• ਲੌਂਗਰਨਿੰਗ ਇੱਕ ਸੰਕੇਤ ਹੈ ਕਿ ਕੰਮ ਤੇਜ਼ੀ ਨਾਲ ਪੂਰਾ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪੂਲ ਤੋਂ ਧਾਗਾ ਨਾ ਲੈਣਾ, ਪਰ ਇਸ ਟਾਸਕ ਲਈ ਇੱਕ ਵੱਖਰਾ ਬਣਾਉਣਾ ਵਿਚਾਰਨਾ ਯੋਗ ਹੋ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਦੂਜਿਆਂ ਨੂੰ ਨੁਕਸਾਨ ਨਾ ਪਹੁੰਚ ਸਕੇ।
• AttachedToParent - ਕਾਰਜਾਂ ਨੂੰ ਲੜੀ ਵਿੱਚ ਵਿਵਸਥਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਇਹ ਵਿਕਲਪ ਵਰਤਿਆ ਗਿਆ ਸੀ, ਤਾਂ ਟਾਸਕ ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਖੁਦ ਪੂਰਾ ਹੋ ਗਿਆ ਹੈ ਅਤੇ ਆਪਣੇ ਬੱਚਿਆਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ।
• PreferFairness - ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬਾਅਦ ਵਿੱਚ ਭੇਜੇ ਗਏ ਕੰਮਾਂ ਤੋਂ ਪਹਿਲਾਂ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਲਈ ਭੇਜੇ ਗਏ ਟਾਸਕ ਨੂੰ ਐਗਜ਼ੀਕਿਊਟ ਕਰਨਾ ਬਿਹਤਰ ਹੋਵੇਗਾ। ਪਰ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਸਿਫ਼ਾਰਸ਼ ਹੈ ਅਤੇ ਨਤੀਜਿਆਂ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਹੈ।

ਵਿਧੀ ਨੂੰ ਪਾਸ ਕੀਤਾ ਗਿਆ ਦੂਜਾ ਪੈਰਾਮੀਟਰ CancellationToken ਹੈ। ਕਿਸੇ ਓਪਰੇਸ਼ਨ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਰੱਦ ਕਰਨ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣ ਲਈ, ਲਾਗੂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਕੋਡ ਕੈਂਸਲੇਸ਼ਨ ਟੋਕਨ ਸਟੇਟ ਲਈ ਚੈੱਕਾਂ ਨਾਲ ਭਰਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਜਾਂਚ ਨਹੀਂ ਹੁੰਦੀ ਹੈ, ਤਾਂ CancelationTokenSource ਆਬਜੈਕਟ 'ਤੇ ਕਾਲ ਕੀਤੀ ਗਈ ਰੱਦ ਕਰਨ ਦੀ ਵਿਧੀ ਟਾਸਕ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਇਸ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਰੋਕਣ ਦੇ ਯੋਗ ਹੋਵੇਗੀ।

ਆਖਰੀ ਪੈਰਾਮੀਟਰ TaskScheduler ਕਿਸਮ ਦਾ ਇੱਕ ਸ਼ਡਿਊਲਰ ਆਬਜੈਕਟ ਹੈ। ਇਹ ਕਲਾਸ ਅਤੇ ਇਸਦੇ ਉੱਤਰਾਧਿਕਾਰੀਆਂ ਨੂੰ ਸਾਰੇ ਥ੍ਰੈੱਡਾਂ ਵਿੱਚ ਕਾਰਜਾਂ ਨੂੰ ਵੰਡਣ ਲਈ ਰਣਨੀਤੀਆਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ; ਮੂਲ ਰੂਪ ਵਿੱਚ, ਟਾਸਕ ਨੂੰ ਪੂਲ ਤੋਂ ਇੱਕ ਬੇਤਰਤੀਬ ਥਰਿੱਡ 'ਤੇ ਚਲਾਇਆ ਜਾਵੇਗਾ।

ਉਡੀਕ ਆਪਰੇਟਰ ਬਣਾਏ ਗਏ ਟਾਸਕ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸਦੇ ਬਾਅਦ ਲਿਖਿਆ ਕੋਡ, ਜੇਕਰ ਕੋਈ ਹੈ, ਤਾਂ ਉਸੇ ਸੰਦਰਭ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ (ਅਕਸਰ ਇਸਦਾ ਅਰਥ ਉਸੇ ਥ੍ਰੈਡ 'ਤੇ ਹੁੰਦਾ ਹੈ) ਜਿਵੇਂ ਕਿ ਉਡੀਕ ਤੋਂ ਪਹਿਲਾਂ ਕੋਡ।

ਵਿਧੀ ਨੂੰ async void ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਉਡੀਕ ਆਪਰੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਕਾਲਿੰਗ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੀ ਉਡੀਕ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ। ਜੇ ਅਜਿਹੀ ਵਿਸ਼ੇਸ਼ਤਾ ਜ਼ਰੂਰੀ ਹੈ, ਤਾਂ ਵਿਧੀ ਨੂੰ ਟਾਸਕ ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ. async void ਮਾਰਕ ਕੀਤੇ ਢੰਗ ਕਾਫ਼ੀ ਆਮ ਹਨ: ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਇਹ ਇਵੈਂਟ ਹੈਂਡਲਰ ਜਾਂ ਹੋਰ ਤਰੀਕੇ ਹਨ ਜੋ ਅੱਗ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਸਿਧਾਂਤ ਨੂੰ ਭੁੱਲ ਜਾਂਦੇ ਹਨ। ਜੇ ਤੁਹਾਨੂੰ ਨਾ ਸਿਰਫ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੇ ਅੰਤ ਤੱਕ ਇੰਤਜ਼ਾਰ ਕਰਨ ਦਾ ਮੌਕਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਨਤੀਜਾ ਵੀ ਵਾਪਸ ਕਰਨਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਟਾਸਕ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.

StartNew ਵਿਧੀ ਦੇ ਨਾਲ ਨਾਲ ਕਿਸੇ ਵੀ ਹੋਰ 'ਤੇ, ਤੁਸੀਂ ਗਲਤ ਪੈਰਾਮੀਟਰ ਦੇ ਨਾਲ ConfigureAwait ਵਿਧੀ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ ਉਡੀਕ ਤੋਂ ਬਾਅਦ ਅਮਲ ਕੈਪਚਰ ਕੀਤੇ ਸੰਦਰਭ 'ਤੇ ਨਹੀਂ, ਸਗੋਂ ਮਨਮਾਨੇ ਢੰਗ ਨਾਲ ਜਾਰੀ ਰਹੇਗਾ। ਇਹ ਹਮੇਸ਼ਾ ਉਦੋਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਉਡੀਕ ਤੋਂ ਬਾਅਦ ਕੋਡ ਲਈ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪ੍ਰਸੰਗ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਇਹ ਕੋਡ ਲਿਖਣ ਵੇਲੇ MS ਦੁਆਰਾ ਇੱਕ ਸਿਫ਼ਾਰਸ਼ ਵੀ ਹੈ ਜੋ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਪੈਕ ਕੀਤਾ ਜਾਵੇਗਾ।

ਆਓ ਥੋੜਾ ਹੋਰ ਧਿਆਨ ਦੇਈਏ ਕਿ ਤੁਸੀਂ ਇੱਕ ਟਾਸਕ ਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕਿਵੇਂ ਕਰ ਸਕਦੇ ਹੋ। ਹੇਠਾਂ ਕੋਡ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਦਿੱਤੀ ਗਈ ਹੈ, ਇਸ 'ਤੇ ਟਿੱਪਣੀਆਂ ਦੇ ਨਾਲ ਕਿ ਉਮੀਦ ਕਦੋਂ ਸ਼ਰਤ ਅਨੁਸਾਰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਜਦੋਂ ਇਹ ਸ਼ਰਤ ਨਾਲ ਮਾੜੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

public static async void AnotherMethod() {

    int result = await AsyncMethod(); // good

    result = AsyncMethod().Result; // bad

    AsyncMethod().Wait(); // bad

    IEnumerable<Task> tasks = new Task[] {
        AsyncMethod(), OtherAsyncMethod()
    };

    await Task.WhenAll(tasks); // good
    await Task.WhenAny(tasks); // good

    Task.WaitAll(tasks.ToArray()); // bad
}

ਪਹਿਲੀ ਉਦਾਹਰਨ ਵਿੱਚ, ਅਸੀਂ ਕਾਲਿੰਗ ਥ੍ਰੈਡ ਨੂੰ ਬਲੌਕ ਕੀਤੇ ਬਿਨਾਂ ਟਾਸਕ ਦੇ ਪੂਰਾ ਹੋਣ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰਦੇ ਹਾਂ; ਅਸੀਂ ਨਤੀਜੇ ਦੀ ਪ੍ਰੋਸੈਸਿੰਗ 'ਤੇ ਉਦੋਂ ਹੀ ਵਾਪਸ ਆਵਾਂਗੇ ਜਦੋਂ ਇਹ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੋਵੇ; ਉਦੋਂ ਤੱਕ, ਕਾਲਿੰਗ ਥ੍ਰੈਡ ਨੂੰ ਇਸਦੇ ਆਪਣੇ ਡਿਵਾਈਸਾਂ 'ਤੇ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਦੂਜੇ ਵਿਕਲਪ ਵਿੱਚ, ਅਸੀਂ ਕਾਲਿੰਗ ਥ੍ਰੈਡ ਨੂੰ ਬਲੌਕ ਕਰਦੇ ਹਾਂ ਜਦੋਂ ਤੱਕ ਵਿਧੀ ਦਾ ਨਤੀਜਾ ਨਹੀਂ ਨਿਕਲਦਾ। ਇਹ ਨਾ ਸਿਰਫ਼ ਇਸ ਲਈ ਮਾੜਾ ਹੈ ਕਿਉਂਕਿ ਅਸੀਂ ਇੱਕ ਥ੍ਰੈੱਡ 'ਤੇ ਕਬਜ਼ਾ ਕਰ ਲਿਆ ਹੈ, ਪ੍ਰੋਗਰਾਮ ਦੇ ਅਜਿਹੇ ਕੀਮਤੀ ਸਰੋਤ, ਸਧਾਰਨ ਆਲਸ ਨਾਲ, ਸਗੋਂ ਇਸ ਲਈ ਵੀ ਕਿਉਂਕਿ ਜੇਕਰ ਸਾਡੇ ਦੁਆਰਾ ਕਾਲ ਕਰਨ ਵਾਲੇ ਢੰਗ ਦੇ ਕੋਡ ਵਿੱਚ ਉਡੀਕ ਹੈ, ਅਤੇ ਸਮਕਾਲੀਕਰਨ ਸੰਦਰਭ ਨੂੰ ਕਾਲਿੰਗ ਥਰਿੱਡ 'ਤੇ ਵਾਪਸ ਜਾਣ ਦੀ ਲੋੜ ਹੈ। ਉਡੀਕ ਕਰੋ, ਫਿਰ ਸਾਨੂੰ ਇੱਕ ਡੈੱਡਲਾਕ ਮਿਲੇਗਾ: ਕਾਲਿੰਗ ਥ੍ਰੈੱਡ ਅਸਿੰਕ੍ਰੋਨਸ ਵਿਧੀ ਦੀ ਗਣਨਾ ਕੀਤੇ ਜਾਣ ਦੇ ਨਤੀਜੇ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਅਸਿੰਕਰੋਨਸ ਵਿਧੀ ਕਾਲਿੰਗ ਥ੍ਰੈੱਡ ਵਿੱਚ ਇਸਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਜਾਰੀ ਰੱਖਣ ਦੀ ਵਿਅਰਥ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ।

ਇਸ ਪਹੁੰਚ ਦਾ ਇੱਕ ਹੋਰ ਨੁਕਸਾਨ ਗੁੰਝਲਦਾਰ ਗਲਤੀ ਹੈਂਡਲਿੰਗ ਹੈ। ਤੱਥ ਇਹ ਹੈ ਕਿ ਅਸਿੰਕ੍ਰੋਨਸ ਕੋਡ ਵਿੱਚ ਤਰੁੱਟੀਆਂ ਜਦੋਂ async/await ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਸੰਭਾਲਣਾ ਬਹੁਤ ਆਸਾਨ ਹੁੰਦਾ ਹੈ - ਉਹ ਉਸੇ ਤਰ੍ਹਾਂ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ ਜਿਵੇਂ ਕੋਡ ਸਮਕਾਲੀ ਸੀ। ਜਦੋਂ ਕਿ ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਟਾਸਕ ਲਈ ਸਮਕਾਲੀ ਵੇਟ ਐਕਸੋਰਸਿਜ਼ਮ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸਲ ਅਪਵਾਦ ਇੱਕ AggregateException ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਅਪਵਾਦ ਨੂੰ ਸੰਭਾਲਣ ਲਈ, ਤੁਹਾਨੂੰ InnerException ਕਿਸਮ ਦੀ ਜਾਂਚ ਕਰਨੀ ਪਵੇਗੀ ਅਤੇ C# ਸੰਸਾਰ ਵਿੱਚ ਵਧੇਰੇ ਜਾਣੇ-ਪਛਾਣੇ ਕੈਚ ਬਲਾਕਾਂ ਦੀ ਚੇਨ ਦੀ ਬਜਾਏ, ਇੱਕ ਕੈਚ ਬਲਾਕ ਦੇ ਅੰਦਰ ਇੱਕ if ਚੇਨ ਆਪਣੇ ਆਪ ਨੂੰ ਲਿਖਣਾ ਪਵੇਗਾ ਜਾਂ ਨਿਰਮਾਣ ਕਰਨ ਵੇਲੇ ਕੈਚ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਵੇਗੀ।

ਤੀਜੀ ਅਤੇ ਅੰਤਿਮ ਉਦਾਹਰਨਾਂ ਨੂੰ ਵੀ ਇਸੇ ਕਾਰਨ ਕਰਕੇ ਮਾੜਾ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਸਾਰੀਆਂ ਇੱਕੋ ਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ।

ਜਦੋਂ ਕੋਈ ਵੀ ਅਤੇ ਕਦੋਂ ਸਾਰੇ ਤਰੀਕੇ ਕਾਰਜਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਦੀ ਉਡੀਕ ਕਰਨ ਲਈ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਹਨ; ਉਹ ਕਾਰਜਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਨੂੰ ਇੱਕ ਵਿੱਚ ਲਪੇਟਦੇ ਹਨ, ਜੋ ਜਾਂ ਤਾਂ ਉਦੋਂ ਫਾਇਰ ਹੋ ਜਾਵੇਗਾ ਜਦੋਂ ਗਰੁੱਪ ਵਿੱਚੋਂ ਕੋਈ ਟਾਸਕ ਪਹਿਲੀ ਵਾਰ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ ਉਹਨਾਂ ਸਾਰਿਆਂ ਨੇ ਆਪਣਾ ਅਮਲ ਪੂਰਾ ਕਰ ਲਿਆ ਹੁੰਦਾ ਹੈ।

ਥਰਿੱਡਾਂ ਨੂੰ ਰੋਕਣਾ

ਕਈ ਕਾਰਨਾਂ ਕਰਕੇ, ਇਸ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵਹਾਅ ਨੂੰ ਰੋਕਣਾ ਜ਼ਰੂਰੀ ਹੋ ਸਕਦਾ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਦੇ ਕਈ ਤਰੀਕੇ ਹਨ। ਥ੍ਰੈਡ ਕਲਾਸ ਵਿੱਚ ਦੋ ਢੁਕਵੇਂ ਨਾਮ ਵਾਲੇ ਢੰਗ ਹਨ: ਅਧੂਰਾ ਛੱਡੋ и ਇੰਟਰੱਪਟ. ਪਹਿਲੇ ਨੂੰ ਵਰਤਣ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ, ਕਿਉਂਕਿ ਕਿਸੇ ਵੀ ਬੇਤਰਤੀਬੇ ਪਲ 'ਤੇ ਇਸ ਨੂੰ ਕਾਲ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਕਿਸੇ ਹਦਾਇਤ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ, ਇੱਕ ਅਪਵਾਦ ਦਿੱਤਾ ਜਾਵੇਗਾ ThreadAbortedException. ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਪੂਰਨ ਅੰਕ ਵੇਰੀਏਬਲ ਨੂੰ ਵਧਾਉਣ ਵੇਲੇ ਅਜਿਹੇ ਅਪਵਾਦ ਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰਦੇ ਹੋ, ਠੀਕ ਹੈ? ਅਤੇ ਇਸ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਅਸਲ ਸਥਿਤੀ ਹੈ. ਜੇਕਰ ਤੁਹਾਨੂੰ ਕੋਡ ਦੇ ਇੱਕ ਖਾਸ ਭਾਗ ਵਿੱਚ CLR ਨੂੰ ਅਜਿਹਾ ਅਪਵਾਦ ਪੈਦਾ ਕਰਨ ਤੋਂ ਰੋਕਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਕਾਲਾਂ ਵਿੱਚ ਲਪੇਟ ਸਕਦੇ ਹੋ ਥ੍ਰੈੱਡ.ਬੀਗਿਨਕ੍ਰਿਟਿਕਲ ਰੀਜਨ, Thread.EndCriticalRegion. ਅੰਤ ਵਿੱਚ ਬਲਾਕ ਵਿੱਚ ਲਿਖਿਆ ਕੋਈ ਵੀ ਕੋਡ ਅਜਿਹੀਆਂ ਕਾਲਾਂ ਵਿੱਚ ਲਪੇਟਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਕਾਰਨ ਕਰਕੇ, ਫਰੇਮਵਰਕ ਕੋਡ ਦੀ ਡੂੰਘਾਈ ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ ਖਾਲੀ ਕੋਸ਼ਿਸ਼ ਨਾਲ ਬਲਾਕ ਲੱਭ ਸਕਦੇ ਹੋ, ਪਰ ਅੰਤ ਵਿੱਚ ਖਾਲੀ ਨਹੀਂ। ਮਾਈਕ੍ਰੋਸਾਫਟ ਇਸ ਵਿਧੀ ਨੂੰ ਇੰਨਾ ਨਿਰਾਸ਼ ਕਰਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ .net ਕੋਰ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ।

ਇੰਟਰੱਪਟ ਵਿਧੀ ਵਧੇਰੇ ਅਨੁਮਾਨ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ। ਇਹ ਇੱਕ ਅਪਵਾਦ ਦੇ ਨਾਲ ਥਰਿੱਡ ਵਿੱਚ ਵਿਘਨ ਪਾ ਸਕਦਾ ਹੈ ThreadInterruptedException ਸਿਰਫ਼ ਉਹਨਾਂ ਪਲਾਂ ਦੌਰਾਨ ਜਦੋਂ ਧਾਗਾ ਉਡੀਕ ਅਵਸਥਾ ਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਇਹ WaitHandle, ਲਾਕ, ਜਾਂ Thread.Sleep ਨੂੰ ਕਾਲ ਕਰਨ ਤੋਂ ਬਾਅਦ ਲਟਕਦੇ ਹੋਏ ਇਸ ਅਵਸਥਾ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦਾ ਹੈ।

ਉੱਪਰ ਦੱਸੇ ਗਏ ਦੋਵੇਂ ਵਿਕਲਪ ਉਹਨਾਂ ਦੀ ਅਪ੍ਰਮਾਣਿਤਤਾ ਦੇ ਕਾਰਨ ਮਾੜੇ ਹਨ। ਹੱਲ ਇੱਕ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ ਰੱਦ ਕਰਨ ਦਾ ਟੋਕਨ ਅਤੇ ਕਲਾਸ ਰੱਦ ਕਰਨ ਦਾ ਟੋਕਨ ਸਰੋਤ. ਬਿੰਦੂ ਇਹ ਹੈ: CancellationTokenSource ਕਲਾਸ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਬਣਾਈ ਗਈ ਹੈ ਅਤੇ ਸਿਰਫ ਉਹੀ ਜੋ ਇਸਦਾ ਮਾਲਕ ਹੈ ਵਿਧੀ ਨੂੰ ਕਾਲ ਕਰਕੇ ਕਾਰਵਾਈ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ ਰੱਦ ਕਰੋ. ਸਿਰਫ਼ ਕੈਂਸਲੇਸ਼ਨ ਟੋਕਨ ਹੀ ਆਪਰੇਸ਼ਨ ਨੂੰ ਪਾਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। CancellationToken ਦੇ ਮਾਲਕ ਆਪਰੇਸ਼ਨ ਨੂੰ ਰੱਦ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਪਰ ਸਿਰਫ਼ ਇਹ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਕੀ ਓਪਰੇਸ਼ਨ ਰੱਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਇਸਦੇ ਲਈ ਇੱਕ ਬੁਲੀਅਨ ਜਾਇਦਾਦ ਹੈ ਰੱਦ ਕਰਨ ਦੀ ਬੇਨਤੀ ਕੀਤੀ ਗਈ ਅਤੇ ਢੰਗ ThrowIfCancel ਬੇਨਤੀ ਕੀਤੀ ਗਈ. ਬਾਅਦ ਵਾਲਾ ਇੱਕ ਅਪਵਾਦ ਸੁੱਟ ਦੇਵੇਗਾ TaskCancelledException ਜੇਕਰ ਕੈਂਸਲੇਸ਼ਨ ਟੋਕਨ ਉਦਾਹਰਨ ਨੂੰ ਤੋਤੇ ਕੀਤੇ ਜਾਣ 'ਤੇ ਰੱਦ ਵਿਧੀ ਨੂੰ ਬੁਲਾਇਆ ਗਿਆ ਸੀ। ਅਤੇ ਇਹ ਉਹ ਤਰੀਕਾ ਹੈ ਜੋ ਮੈਂ ਵਰਤਣ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ. ਇਹ ਪਿਛਲੇ ਵਿਕਲਪਾਂ ਨਾਲੋਂ ਇੱਕ ਸੁਧਾਰ ਹੈ ਜਿਸ 'ਤੇ ਪੂਰਾ ਨਿਯੰਤਰਣ ਪ੍ਰਾਪਤ ਕਰਕੇ ਇੱਕ ਅਪਵਾਦ ਕਾਰਵਾਈ ਨੂੰ ਕਿਸ ਬਿੰਦੂ 'ਤੇ ਬੰਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇੱਕ ਥਰਿੱਡ ਨੂੰ ਰੋਕਣ ਲਈ ਸਭ ਤੋਂ ਬੇਰਹਿਮ ਵਿਕਲਪ ਹੈ Win32 API TerminateThread ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਨਾ। ਇਸ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਨ ਤੋਂ ਬਾਅਦ CLR ਦਾ ਵਿਵਹਾਰ ਅਣ-ਅਨੁਮਾਨਿਤ ਹੋ ਸਕਦਾ ਹੈ। MSDN 'ਤੇ ਇਸ ਫੰਕਸ਼ਨ ਬਾਰੇ ਹੇਠਾਂ ਲਿਖਿਆ ਗਿਆ ਹੈ: "TerminateThread ਇੱਕ ਖ਼ਤਰਨਾਕ ਫੰਕਸ਼ਨ ਹੈ ਜੋ ਸਿਰਫ ਸਭ ਤੋਂ ਵੱਧ ਗੰਭੀਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। "

FromAsync ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੁਰਾਤਨ API ਨੂੰ ਟਾਸਕ ਬੇਸਡ ਵਿੱਚ ਬਦਲਣਾ

ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਅਜਿਹੇ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਖੁਸ਼ਕਿਸਮਤ ਸੀ ਜੋ ਟਾਸਕ ਪੇਸ਼ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰਾਂ ਲਈ ਸ਼ਾਂਤ ਡਰਾਉਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰੇ ਪੁਰਾਣੇ APIs ਨਾਲ ਨਜਿੱਠਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਵੇਗੀ, ਦੋਵੇਂ ਤੀਜੀ-ਧਿਰ ਵਾਲੇ ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ। ਨੇ ਅਤੀਤ ਵਿੱਚ ਤਸੀਹੇ ਦਿੱਤੇ ਹਨ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, .NET ਫਰੇਮਵਰਕ ਟੀਮ ਨੇ ਸਾਡੀ ਦੇਖਭਾਲ ਕੀਤੀ, ਹਾਲਾਂਕਿ ਸ਼ਾਇਦ ਟੀਚਾ ਆਪਣੀ ਦੇਖਭਾਲ ਕਰਨਾ ਸੀ। ਜਿਵੇਂ ਕਿ ਇਹ ਹੋ ਸਕਦਾ ਹੈ, .NET ਕੋਲ ਪੁਰਾਣੇ ਅਸਿੰਕ੍ਰੋਨਸ ਪ੍ਰੋਗਰਾਮਿੰਗ ਪਹੁੰਚਾਂ ਵਿੱਚ ਲਿਖੇ ਕੋਡ ਨੂੰ ਨਵੇਂ ਵਿੱਚ ਦਰਦ ਰਹਿਤ ਰੂਪਾਂਤਰਣ ਲਈ ਬਹੁਤ ਸਾਰੇ ਟੂਲ ਹਨ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਟਾਸਕਫੈਕਟਰੀ ਦੀ FromAsync ਵਿਧੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਕੋਡ ਉਦਾਹਰਨ ਵਿੱਚ, ਮੈਂ ਇਸ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਟਾਸਕ ਵਿੱਚ WebRequest ਕਲਾਸ ਦੀਆਂ ਪੁਰਾਣੀਆਂ ਅਸਿੰਕਰੋਨਸ ਵਿਧੀਆਂ ਨੂੰ ਲਪੇਟਦਾ ਹਾਂ।

object state = null;
WebRequest wr = WebRequest.CreateHttp("http://github.com");
await Task.Factory.FromAsync(
    wr.BeginGetResponse,
    we.EndGetResponse
);

ਇਹ ਸਿਰਫ਼ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਬਿਲਟ-ਇਨ ਕਿਸਮਾਂ ਨਾਲ ਅਜਿਹਾ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ, ਪਰ ਕੋਈ ਵੀ ਪੁਰਾਣਾ ਪ੍ਰੋਜੈਕਟ ਸਿਰਫ਼ BeginDoSomething ਢੰਗਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ IAsyncResult ਅਤੇ EndDoSomething ਵਿਧੀਆਂ ਨੂੰ ਵਾਪਸ ਕਰਦੇ ਹਨ।

TaskCompletionSource ਕਲਾਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੁਰਾਤਨ API ਨੂੰ Task Based ਵਿੱਚ ਬਦਲੋ

ਵਿਚਾਰ ਕਰਨ ਲਈ ਇਕ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਸਾਧਨ ਕਲਾਸ ਹੈ TaskCompletionSource. ਫੰਕਸ਼ਨਾਂ, ਉਦੇਸ਼ ਅਤੇ ਸੰਚਾਲਨ ਦੇ ਸਿਧਾਂਤ ਦੇ ਸੰਦਰਭ ਵਿੱਚ, ਇਹ ਥ੍ਰੈਡਪੂਲ ਕਲਾਸ ਦੇ RegisterWaitForSingleObject ਵਿਧੀ ਦੀ ਕੁਝ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ, ਜਿਸ ਬਾਰੇ ਮੈਂ ਉੱਪਰ ਲਿਖਿਆ ਸੀ। ਇਸ ਕਲਾਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਤੁਸੀਂ ਟਾਸਕ ਵਿੱਚ ਪੁਰਾਣੇ ਅਸਿੰਕ੍ਰੋਨਸ API ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਅਤੇ ਸੁਵਿਧਾਜਨਕ ਰੂਪ ਵਿੱਚ ਸਮੇਟ ਸਕਦੇ ਹੋ।

ਤੁਸੀਂ ਕਹੋਗੇ ਕਿ ਮੈਂ ਇਹਨਾਂ ਉਦੇਸ਼ਾਂ ਲਈ ਤਿਆਰ ਕੀਤੇ ਟਾਸਕਫੈਕਟਰੀ ਕਲਾਸ ਦੇ FromAsync ਵਿਧੀ ਬਾਰੇ ਪਹਿਲਾਂ ਹੀ ਗੱਲ ਕਰ ਚੁੱਕਾ ਹਾਂ। ਇੱਥੇ ਸਾਨੂੰ .net ਵਿੱਚ ਅਸਿੰਕ੍ਰੋਨਸ ਮਾਡਲਾਂ ਦੇ ਵਿਕਾਸ ਦੇ ਪੂਰੇ ਇਤਿਹਾਸ ਨੂੰ ਯਾਦ ਰੱਖਣਾ ਹੋਵੇਗਾ ਜੋ ਮਾਈਕਰੋਸਾਫਟ ਨੇ ਪਿਛਲੇ 15 ਸਾਲਾਂ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਹੈ: ਟਾਸਕ-ਬੇਸਡ ਅਸਿੰਕ੍ਰੋਨਸ ਪੈਟਰਨ (TAP) ਤੋਂ ਪਹਿਲਾਂ, ਅਸਿੰਕ੍ਰੋਨਸ ਪ੍ਰੋਗਰਾਮਿੰਗ ਪੈਟਰਨ (APP), ਜੋ ਤਰੀਕਿਆਂ ਬਾਰੇ ਸੀ ਸ਼ੁਰੂ ਕਰੋਕੀ ਕੁਝ ਵਾਪਸ ਆ ਰਿਹਾ ਹੈ IAsyncResult ਅਤੇ ਢੰਗ ਅੰਤDoSomething ਜੋ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹਨਾਂ ਸਾਲਾਂ ਦੀ ਵਿਰਾਸਤ ਲਈ FromAsync ਵਿਧੀ ਬਿਲਕੁਲ ਸਹੀ ਹੈ, ਪਰ ਸਮੇਂ ਦੇ ਨਾਲ, ਇਸਨੂੰ ਇਵੈਂਟ ਅਧਾਰਤ ਅਸਿੰਕ੍ਰੋਨਸ ਪੈਟਰਨ (EAP), ਜਿਸ ਨੇ ਇਹ ਮੰਨਿਆ ਕਿ ਅਸਿੰਕ੍ਰੋਨਸ ਓਪਰੇਸ਼ਨ ਪੂਰਾ ਹੋਣ 'ਤੇ ਇੱਕ ਇਵੈਂਟ ਉਭਾਰਿਆ ਜਾਵੇਗਾ।

TaskCompletionSource ਇਵੈਂਟ ਮਾਡਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣੇ Tasks ਅਤੇ ਪੁਰਾਤਨ API ਨੂੰ ਸਮੇਟਣ ਲਈ ਸੰਪੂਰਨ ਹੈ। ਇਸਦੇ ਕੰਮ ਦਾ ਨਿਚੋੜ ਇਸ ਪ੍ਰਕਾਰ ਹੈ: ਇਸ ਕਲਾਸ ਦੀ ਇੱਕ ਵਸਤੂ ਵਿੱਚ ਟਾਸਕ ਕਿਸਮ ਦੀ ਇੱਕ ਜਨਤਕ ਜਾਇਦਾਦ ਹੈ, ਜਿਸ ਦੀ ਸਥਿਤੀ ਨੂੰ TaskCompletionSource ਕਲਾਸ ਦੇ SetResult, SetException, ਆਦਿ ਤਰੀਕਿਆਂ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਜਿੱਥੇ ਉਡੀਕ ਓਪਰੇਟਰ ਨੂੰ ਇਸ ਟਾਸਕ ਲਈ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ, ਇਹ ਟਾਸਕਕੰਪਲਸ਼ਨ ਸਰੋਤ 'ਤੇ ਲਾਗੂ ਕੀਤੇ ਗਏ ਢੰਗ ਦੇ ਆਧਾਰ 'ਤੇ ਅਪਵਾਦ ਦੇ ਨਾਲ ਚਲਾਇਆ ਜਾਵੇਗਾ ਜਾਂ ਅਸਫਲ ਹੋ ਜਾਵੇਗਾ। ਜੇਕਰ ਇਹ ਅਜੇ ਵੀ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ, ਤਾਂ ਆਓ ਇਸ ਕੋਡ ਉਦਾਹਰਨ ਨੂੰ ਵੇਖੀਏ, ਜਿੱਥੇ ਕੁਝ ਪੁਰਾਣੇ EAP API ਨੂੰ ਇੱਕ TaskCompletionSource ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਟਾਸਕ ਵਿੱਚ ਲਪੇਟਿਆ ਗਿਆ ਹੈ: ਜਦੋਂ ਇਵੈਂਟ ਫਾਇਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਟਾਸਕ ਨੂੰ ਮੁਕੰਮਲ ਸਥਿਤੀ ਵਿੱਚ ਰੱਖਿਆ ਜਾਵੇਗਾ, ਅਤੇ ਉਹ ਵਿਧੀ ਜੋ ਉਡੀਕ ਆਪਰੇਟਰ ਨੂੰ ਲਾਗੂ ਕਰਦੀ ਹੈ। ਇਸ ਟਾਸਕ ਨੂੰ ਆਬਜੈਕਟ ਪ੍ਰਾਪਤ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਸ ਦੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਮੁੜ ਸ਼ੁਰੂ ਹੋ ਜਾਵੇਗੀ ਇਸ ਦਾ ਨਤੀਜਾ.

public static Task<Result> DoAsync(this SomeApiInstance someApiObj) {

    var completionSource = new TaskCompletionSource<Result>();
    someApiObj.Done += 
        result => completionSource.SetResult(result);
    someApiObj.Do();

    result completionSource.Task;
}

TaskCompletionSource ਟਿਪਸ ਅਤੇ ਟ੍ਰਿਕਸ

ਪੁਰਾਣੇ API ਨੂੰ ਸਮੇਟਣਾ ਉਹ ਸਭ ਕੁਝ ਨਹੀਂ ਹੈ ਜੋ TaskCompletionSource ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਕਲਾਸ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਉਹਨਾਂ ਟਾਸਕਾਂ 'ਤੇ ਵੱਖ-ਵੱਖ API ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਇੱਕ ਦਿਲਚਸਪ ਸੰਭਾਵਨਾ ਨੂੰ ਖੋਲ੍ਹਦਾ ਹੈ ਜੋ ਥਰਿੱਡਾਂ 'ਤੇ ਕਬਜ਼ਾ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਅਤੇ ਸਟ੍ਰੀਮ, ਜਿਵੇਂ ਕਿ ਸਾਨੂੰ ਯਾਦ ਹੈ, ਇੱਕ ਮਹਿੰਗਾ ਸਰੋਤ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੀ ਗਿਣਤੀ ਸੀਮਤ ਹੈ (ਮੁੱਖ ਤੌਰ 'ਤੇ RAM ਦੀ ਮਾਤਰਾ ਦੁਆਰਾ). ਇਹ ਸੀਮਾ ਆਸਾਨੀ ਨਾਲ ਵਿਕਸਤ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਗੁੰਝਲਦਾਰ ਵਪਾਰਕ ਤਰਕ ਨਾਲ ਇੱਕ ਲੋਡ ਕੀਤੀ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ। ਆਉ ਉਹਨਾਂ ਸੰਭਾਵਨਾਵਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰੀਏ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਮੈਂ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ ਜਦੋਂ ਲੌਂਗ-ਪੋਲਿੰਗ ਵਰਗੀ ਚਾਲ ਨੂੰ ਲਾਗੂ ਕਰਨਾ.

ਸੰਖੇਪ ਵਿੱਚ, ਚਾਲ ਦਾ ਸਾਰ ਇਹ ਹੈ: ਤੁਹਾਨੂੰ API ਤੋਂ ਇਸਦੇ ਪਾਸੇ ਹੋਣ ਵਾਲੀਆਂ ਕੁਝ ਘਟਨਾਵਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਜਦੋਂ ਕਿ API, ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ, ਘਟਨਾ ਦੀ ਰਿਪੋਰਟ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਪਰ ਸਿਰਫ ਸਥਿਤੀ ਨੂੰ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ। ਇਹਨਾਂ ਦੀ ਇੱਕ ਉਦਾਹਰਨ WebSocket ਦੇ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ HTTP ਦੇ ਸਿਖਰ 'ਤੇ ਬਣੇ ਸਾਰੇ API ਹਨ ਜਾਂ ਜਦੋਂ ਇਸ ਤਕਨਾਲੋਜੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਅਸੰਭਵ ਸੀ। ਕਲਾਇੰਟ HTTP ਸਰਵਰ ਨੂੰ ਪੁੱਛ ਸਕਦਾ ਹੈ। HTTP ਸਰਵਰ ਆਪਣੇ ਆਪ ਕਲਾਇੰਟ ਨਾਲ ਸੰਚਾਰ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਹੱਲ ਹੈ ਇੱਕ ਟਾਈਮਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਰਵਰ ਨੂੰ ਪੋਲ ਕਰਨਾ, ਪਰ ਇਹ ਸਰਵਰ 'ਤੇ ਇੱਕ ਵਾਧੂ ਲੋਡ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਔਸਤ TimerInterval / 2 'ਤੇ ਇੱਕ ਵਾਧੂ ਦੇਰੀ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਲੌਂਗ ਪੋਲਿੰਗ ਨਾਮਕ ਇੱਕ ਚਾਲ ਦੀ ਖੋਜ ਕੀਤੀ ਗਈ ਸੀ, ਜਿਸ ਵਿੱਚ ਜਵਾਬ ਵਿੱਚ ਦੇਰੀ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ। ਸਰਵਰ ਜਦੋਂ ਤੱਕ ਸਮਾਂ ਸਮਾਪਤ ਨਹੀਂ ਹੁੰਦਾ ਜਾਂ ਕੋਈ ਘਟਨਾ ਵਾਪਰਦੀ ਹੈ। ਜੇਕਰ ਕੋਈ ਘਟਨਾ ਵਾਪਰਦੀ ਹੈ, ਤਾਂ ਇਸ 'ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ; ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਬੇਨਤੀ ਦੁਬਾਰਾ ਭੇਜੀ ਜਾਂਦੀ ਹੈ।

while(!eventOccures && !timeoutExceeded)  {

  CheckTimout();
  CheckEvent();
  Thread.Sleep(1);
}

ਪਰ ਘਟਨਾ ਦੀ ਉਡੀਕ ਕਰਨ ਵਾਲੇ ਗਾਹਕਾਂ ਦੀ ਗਿਣਤੀ ਵਧਣ ਦੇ ਨਾਲ ਹੀ ਅਜਿਹਾ ਹੱਲ ਭਿਆਨਕ ਸਾਬਤ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ... ਹਰੇਕ ਅਜਿਹਾ ਕਲਾਇੰਟ ਇੱਕ ਇਵੈਂਟ ਦੀ ਉਡੀਕ ਵਿੱਚ ਇੱਕ ਪੂਰਾ ਥਰਿੱਡ ਰੱਖਦਾ ਹੈ। ਹਾਂ, ਅਤੇ ਜਦੋਂ ਇਵੈਂਟ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਤਾਂ ਸਾਨੂੰ ਇੱਕ ਵਾਧੂ 1ms ਦੇਰੀ ਮਿਲਦੀ ਹੈ, ਅਕਸਰ ਇਹ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੁੰਦਾ ਹੈ, ਪਰ ਸਾਫਟਵੇਅਰ ਨੂੰ ਇਸ ਤੋਂ ਬਦਤਰ ਕਿਉਂ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ? ਜੇਕਰ ਅਸੀਂ Thread.Sleep(1) ਨੂੰ ਹਟਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਵਿਅਰਥ ਵਿੱਚ ਅਸੀਂ ਇੱਕ ਪ੍ਰੋਸੈਸਰ ਕੋਰ 100% ਨਿਸ਼ਕਿਰਿਆ, ਇੱਕ ਬੇਕਾਰ ਚੱਕਰ ਵਿੱਚ ਘੁੰਮਦੇ ਹੋਏ ਲੋਡ ਕਰਾਂਗੇ। TaskCompletionSource ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੁਸੀਂ ਇਸ ਕੋਡ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਰੀਮੇਕ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਉਪਰੋਕਤ ਪਛਾਣੀਆਂ ਗਈਆਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰ ਸਕਦੇ ਹੋ:

class LongPollingApi {

    private Dictionary<int, TaskCompletionSource<Msg>> tasks;

    public async Task<Msg> AcceptMessageAsync(int userId, int duration) {

        var cs = new TaskCompletionSource<Msg>();
        tasks[userId] = cs;
        await Task.WhenAny(Task.Delay(duration), cs.Task);
        return cs.Task.IsCompleted ? cs.Task.Result : null;
    }

    public void SendMessage(int userId, Msg m) {

        if (tasks.TryGetValue(userId, out var completionSource))
            completionSource.SetResult(m);
    }
}

ਇਹ ਕੋਡ ਉਤਪਾਦਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੈ, ਪਰ ਸਿਰਫ਼ ਇੱਕ ਡੈਮੋ ਹੈ। ਅਸਲ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਘੱਟੋ-ਘੱਟ ਸਥਿਤੀ ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇੱਕ ਸੁਨੇਹਾ ਅਜਿਹੇ ਸਮੇਂ ਵਿੱਚ ਆਉਂਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਵੀ ਇਸਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ: ਇਸ ਸਥਿਤੀ ਵਿੱਚ, AsseptMessageAsync ਵਿਧੀ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪੂਰਾ ਕੀਤਾ ਕੰਮ ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਇਹ ਸਭ ਤੋਂ ਆਮ ਕੇਸ ਹੈ, ਤਾਂ ਤੁਸੀਂ ValueTask ਦੀ ਵਰਤੋਂ ਕਰਨ ਬਾਰੇ ਸੋਚ ਸਕਦੇ ਹੋ.

ਜਦੋਂ ਸਾਨੂੰ ਕਿਸੇ ਸੁਨੇਹੇ ਲਈ ਬੇਨਤੀ ਮਿਲਦੀ ਹੈ, ਤਾਂ ਅਸੀਂ ਸ਼ਬਦਕੋਸ਼ ਵਿੱਚ ਇੱਕ TaskCompletionSource ਬਣਾਉਂਦੇ ਹਾਂ ਅਤੇ ਰੱਖਦੇ ਹਾਂ, ਅਤੇ ਫਿਰ ਪਹਿਲਾਂ ਕੀ ਹੁੰਦਾ ਹੈ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹਾਂ: ਨਿਰਧਾਰਤ ਸਮੇਂ ਦੇ ਅੰਤਰਾਲ ਦੀ ਮਿਆਦ ਪੁੱਗ ਜਾਂਦੀ ਹੈ ਜਾਂ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ।

ValueTask: ਕਿਉਂ ਅਤੇ ਕਿਵੇਂ

async/await ਓਪਰੇਟਰ, ਜਿਵੇਂ ਕਿ ਯੀਲਡ ਰਿਟਰਨ ਆਪਰੇਟਰ, ਵਿਧੀ ਤੋਂ ਇੱਕ ਸਟੇਟ ਮਸ਼ੀਨ ਤਿਆਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਇੱਕ ਨਵੀਂ ਵਸਤੂ ਦੀ ਸਿਰਜਣਾ ਹੈ, ਜੋ ਲਗਭਗ ਹਮੇਸ਼ਾ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੁੰਦਾ ਹੈ, ਪਰ ਬਹੁਤ ਘੱਟ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਹ ਇੱਕ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਕੇਸ ਇੱਕ ਅਜਿਹਾ ਤਰੀਕਾ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸਨੂੰ ਅਸਲ ਵਿੱਚ ਅਕਸਰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਅਸੀਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਹਜ਼ਾਰਾਂ ਕਾਲਾਂ ਅਤੇ ਹਜ਼ਾਰਾਂ ਕਾਲਾਂ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ. ਜੇਕਰ ਅਜਿਹੀ ਵਿਧੀ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਲਿਖਿਆ ਗਿਆ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਹ ਉਡੀਕ ਦੇ ਸਾਰੇ ਤਰੀਕਿਆਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰਕੇ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ .NET ਇਸ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਇੱਕ ਸਾਧਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ - ValueTask ਢਾਂਚਾ। ਇਸ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਲਈ, ਆਓ ਇਸਦੀ ਵਰਤੋਂ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਵੇਖੀਏ: ਇੱਥੇ ਇੱਕ ਕੈਸ਼ ਹੈ ਜਿਸ ਨੂੰ ਅਸੀਂ ਅਕਸਰ ਜਾਂਦੇ ਹਾਂ। ਇਸ ਵਿੱਚ ਕੁਝ ਮੁੱਲ ਹਨ ਅਤੇ ਫਿਰ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਵਾਪਸ ਕਰਦੇ ਹਾਂ; ਜੇ ਨਹੀਂ, ਤਾਂ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕੁਝ ਹੌਲੀ IO ਤੇ ਜਾਂਦੇ ਹਾਂ. ਮੈਂ ਬਾਅਦ ਵਾਲੇ ਨੂੰ ਅਸਿੰਕਰੋਨਸ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪੂਰੀ ਵਿਧੀ ਅਸਿੰਕਰੋਨਸ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਵਿਧੀ ਨੂੰ ਲਿਖਣ ਦਾ ਸਪਸ਼ਟ ਤਰੀਕਾ ਇਸ ਪ੍ਰਕਾਰ ਹੈ:

public async Task<string> GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return val;
    return await RequestById(id);
}

ਥੋੜਾ ਜਿਹਾ ਅਨੁਕੂਲਿਤ ਕਰਨ ਦੀ ਇੱਛਾ ਦੇ ਕਾਰਨ, ਅਤੇ ਇਸ ਕੋਡ ਨੂੰ ਕੰਪਾਇਲ ਕਰਨ ਵੇਲੇ ਰੋਸਲਿਨ ਕੀ ਪੈਦਾ ਕਰੇਗਾ, ਇਸ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ ਡਰ, ਤੁਸੀਂ ਇਸ ਉਦਾਹਰਨ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੁਬਾਰਾ ਲਿਖ ਸਕਦੇ ਹੋ:

public Task<string> GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return Task.FromResult(val);
    return RequestById(id);
}

ਦਰਅਸਲ, ਇਸ ਕੇਸ ਵਿੱਚ ਸਰਵੋਤਮ ਹੱਲ ਹੌਟ-ਪਾਥ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਹੋਵੇਗਾ, ਅਰਥਾਤ, ਬਿਨਾਂ ਕਿਸੇ ਬੇਲੋੜੀ ਵੰਡ ਅਤੇ ਜੀਸੀ ਉੱਤੇ ਲੋਡ ਕੀਤੇ ਡਿਕਸ਼ਨਰੀ ਤੋਂ ਇੱਕ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਨਾ, ਜਦੋਂ ਕਿ ਉਹਨਾਂ ਦੁਰਲੱਭ ਮਾਮਲਿਆਂ ਵਿੱਚ ਜਦੋਂ ਸਾਨੂੰ ਅਜੇ ਵੀ ਡੇਟਾ ਲਈ IO ਤੇ ਜਾਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। , ਸਭ ਕੁਝ ਪੁਰਾਣੇ ਤਰੀਕੇ ਨਾਲ ਪਲੱਸ/ਮਾਇਨਸ ਰਹੇਗਾ:

public ValueTask<string> GetById(int id) {

    if (cache.TryGetValue(id, out string val))
        return new ValueTask<string>(val);
    return new ValueTask<string>(RequestById(id));
}

ਆਓ ਕੋਡ ਦੇ ਇਸ ਟੁਕੜੇ 'ਤੇ ਡੂੰਘਾਈ ਨਾਲ ਵਿਚਾਰ ਕਰੀਏ: ਜੇਕਰ ਕੈਸ਼ ਵਿੱਚ ਕੋਈ ਮੁੱਲ ਹੈ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਢਾਂਚਾ ਬਣਾਉਂਦੇ ਹਾਂ, ਨਹੀਂ ਤਾਂ ਅਸਲ ਕੰਮ ਨੂੰ ਇੱਕ ਅਰਥਪੂਰਨ ਵਿੱਚ ਲਪੇਟਿਆ ਜਾਵੇਗਾ। ਕਾਲਿੰਗ ਕੋਡ ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਕੋਡ ਕਿਸ ਮਾਰਗ ਵਿੱਚ ਚਲਾਇਆ ਗਿਆ ਸੀ: ValueTask, ਇੱਕ C# ਸੰਟੈਕਸ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਸ ਕੇਸ ਵਿੱਚ ਇੱਕ ਨਿਯਮਤ ਟਾਸਕ ਵਾਂਗ ਹੀ ਵਿਵਹਾਰ ਕਰੇਗਾ।

ਟਾਸਕ ਸ਼ੈਡਿਊਲਰ: ਟਾਸਕ ਲਾਂਚ ਰਣਨੀਤੀਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ

ਅਗਲਾ API ਜਿਸ ਬਾਰੇ ਮੈਂ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹਾਂਗਾ ਉਹ ਹੈ ਕਲਾਸ ਟਾਸਕ-ਸ਼ੈਡਿਊਲਰ ਅਤੇ ਇਸਦੇ ਡੈਰੀਵੇਟਿਵਜ਼। ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਉੱਪਰ ਜ਼ਿਕਰ ਕੀਤਾ ਹੈ ਕਿ TPL ਕੋਲ ਸਾਰੇ ਥ੍ਰੈਡਾਂ ਵਿੱਚ ਕਾਰਜਾਂ ਨੂੰ ਵੰਡਣ ਲਈ ਰਣਨੀਤੀਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ। ਅਜਿਹੀਆਂ ਰਣਨੀਤੀਆਂ ਨੂੰ TaskScheduler ਕਲਾਸ ਦੇ ਉੱਤਰਾਧਿਕਾਰੀਆਂ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਲਗਭਗ ਕੋਈ ਵੀ ਰਣਨੀਤੀ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਲੱਭੀ ਜਾ ਸਕਦੀ ਹੈ। ਸਮਾਨਾਂਤਰ ਐਕਸਟੈਂਸ਼ਨ ਐਕਸਟਰਾ, Microsoft ਦੁਆਰਾ ਵਿਕਸਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ .NET ਦਾ ਹਿੱਸਾ ਨਹੀਂ ਹੈ, ਪਰ ਇੱਕ Nuget ਪੈਕੇਜ ਵਜੋਂ ਸਪਲਾਈ ਕੀਤਾ ਗਿਆ ਹੈ। ਆਓ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਨੂੰ ਸੰਖੇਪ ਵਿੱਚ ਵੇਖੀਏ:

• CurrentThreadTaskScheduler - ਮੌਜੂਦਾ ਥ੍ਰੈਡ 'ਤੇ ਕੰਮ ਚਲਾਉਂਦਾ ਹੈ
• ਲਿਮਟਿਡ ਕਨਕਰੰਸੀ ਲੈਵਲ ਟਾਸਕ ਸ਼ੈਡਿਊਲਰ — ਪੈਰਾਮੀਟਰ N ਦੁਆਰਾ ਇੱਕੋ ਸਮੇਂ ਚੱਲਣ ਵਾਲੇ ਕਾਰਜਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਕੰਸਟਰਕਟਰ ਵਿੱਚ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
• OrderedTaskScheduler — ਨੂੰ LimitedConcurrencyLevelTaskScheduler(1) ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਇਸਲਈ ਕਾਰਜਾਂ ਨੂੰ ਕ੍ਰਮਵਾਰ ਚਲਾਇਆ ਜਾਵੇਗਾ।
• WorkStealingTaskScheduler - ਉਪਕਰਣ ਕੰਮ-ਚੋਰੀ ਕਾਰਜ ਵੰਡ ਲਈ ਪਹੁੰਚ ਅਸਲ ਵਿੱਚ ਇਹ ਇੱਕ ਵੱਖਰਾ ਥ੍ਰੈਡਪੂਲ ਹੈ। ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਕਿ .NET ਥ੍ਰੈਡਪੂਲ ਵਿੱਚ ਇੱਕ ਸਥਿਰ ਕਲਾਸ ਹੈ, ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਇੱਕ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮ ਦੇ ਇੱਕ ਹਿੱਸੇ ਵਿੱਚ ਇਸਦਾ ਓਵਰਲੋਡਿੰਗ ਜਾਂ ਗਲਤ ਵਰਤੋਂ ਦੂਜੇ ਵਿੱਚ ਮਾੜੇ ਪ੍ਰਭਾਵਾਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਜਿਹੇ ਨੁਕਸ ਦੇ ਕਾਰਨ ਨੂੰ ਸਮਝਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ. ਕਿ. ਪ੍ਰੋਗਰਾਮ ਦੇ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੱਖਰੇ WorkStealingTaskSchedulers ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਜਿੱਥੇ ਥ੍ਰੈਡਪੂਲ ਦੀ ਵਰਤੋਂ ਹਮਲਾਵਰ ਅਤੇ ਅਣਪਛਾਤੀ ਹੋ ਸਕਦੀ ਹੈ।
• ਕਤਾਰਬੱਧ ਟਾਸਕ ਸ਼ੈਡਿਊਲਰ - ਤੁਹਾਨੂੰ ਤਰਜੀਹੀ ਕਤਾਰ ਨਿਯਮਾਂ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ
• ThreadPerTaskScheduler — ਹਰੇਕ ਕੰਮ ਲਈ ਇੱਕ ਵੱਖਰਾ ਥ੍ਰੈਡ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਇਸ ਉੱਤੇ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਉਹਨਾਂ ਕੰਮਾਂ ਲਈ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਜਿਹਨਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਅਚਨਚੇਤ ਲੰਬਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ।

ਇੱਕ ਵਧੀਆ ਵੇਰਵਾ ਹੈ ਲੇਖ ਮਾਈਕ੍ਰੋਸਾਫਟ ਬਲੌਗ 'ਤੇ TaskSchedulers ਬਾਰੇ।

ਟਾਸਕ ਨਾਲ ਸਬੰਧਤ ਹਰ ਚੀਜ਼ ਦੀ ਸੁਵਿਧਾਜਨਕ ਡੀਬੱਗਿੰਗ ਲਈ, ਵਿਜ਼ੂਅਲ ਸਟੂਡੀਓ ਵਿੱਚ ਇੱਕ ਟਾਸਕ ਵਿੰਡੋ ਹੈ। ਇਸ ਵਿੰਡੋ ਵਿੱਚ ਤੁਸੀਂ ਕਾਰਜ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦੇਖ ਸਕਦੇ ਹੋ ਅਤੇ ਕੋਡ ਦੀ ਵਰਤਮਾਨ ਵਿੱਚ ਚੱਲਣ ਵਾਲੀ ਲਾਈਨ 'ਤੇ ਜਾ ਸਕਦੇ ਹੋ।

PLinq ਅਤੇ ਸਮਾਨਾਂਤਰ ਕਲਾਸ

ਟਾਸਕ ਅਤੇ ਉਹਨਾਂ ਬਾਰੇ ਕਹੀ ਗਈ ਹਰ ਚੀਜ਼ ਤੋਂ ਇਲਾਵਾ, .NET ਵਿੱਚ ਦੋ ਹੋਰ ਦਿਲਚਸਪ ਟੂਲ ਹਨ: PLinq (Linq2Parallel) ਅਤੇ ਸਮਾਨਾਂਤਰ ਕਲਾਸ। ਪਹਿਲਾ ਕਈ ਥਰਿੱਡਾਂ 'ਤੇ ਸਾਰੇ ਲਿੰਕ ਓਪਰੇਸ਼ਨਾਂ ਦੇ ਸਮਾਨਾਂਤਰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੈ। ਥਰਿੱਡਾਂ ਦੀ ਗਿਣਤੀ WithDegreeOfParallelism ਐਕਸਟੈਂਸ਼ਨ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਜ਼ਿਆਦਾਤਰ ਅਕਸਰ ਇਸਦੇ ਡਿਫੌਲਟ ਮੋਡ ਵਿੱਚ PLinq ਕੋਲ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਗਤੀ ਲਾਭ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਤੁਹਾਡੇ ਡੇਟਾ ਸਰੋਤ ਦੇ ਅੰਦਰੂਨੀ ਬਾਰੇ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੁੰਦੀ ਹੈ, ਦੂਜੇ ਪਾਸੇ, ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਲਾਗਤ ਬਹੁਤ ਘੱਟ ਹੈ: ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ AsParallel ਵਿਧੀ ਨੂੰ ਕਾਲ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਲਿੰਕ ਤਰੀਕਿਆਂ ਦੀ ਲੜੀ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਓ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਭਾਗ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੁਹਾਡੇ ਡੇਟਾ ਸਰੋਤ ਦੀ ਪ੍ਰਕਿਰਤੀ ਬਾਰੇ PLinq ਨੂੰ ਵਾਧੂ ਜਾਣਕਾਰੀ ਦੇਣਾ ਸੰਭਵ ਹੈ। ਤੁਸੀਂ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਇੱਥੇ и ਇੱਥੇ.

ਪੈਰਲਲ ਸਟੈਟਿਕ ਕਲਾਸ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਇੱਕ ਫੋਰਚ ਸੰਗ੍ਰਹਿ ਦੁਆਰਾ ਦੁਹਰਾਉਣ, ਇੱਕ ਲਈ ਲੂਪ ਨੂੰ ਚਲਾਉਣ, ਅਤੇ ਪੈਰਲਲ ਇਨਵੋਕ ਵਿੱਚ ਕਈ ਡੈਲੀਗੇਟਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਵਿਧੀਆਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਗਣਨਾ ਪੂਰੀ ਹੋਣ ਤੱਕ ਮੌਜੂਦਾ ਥ੍ਰੈੱਡ ਦਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਰੋਕ ਦਿੱਤਾ ਜਾਵੇਗਾ। ਥਰਿੱਡਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਆਖਰੀ ਆਰਗੂਮੈਂਟ ਦੇ ਤੌਰ 'ਤੇ ParallelOptions ਪਾਸ ਕਰਕੇ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਵਿਕਲਪਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ TaskScheduler ਅਤੇ CancellationToken ਵੀ ਨਿਰਧਾਰਿਤ ਕਰ ਸਕਦੇ ਹੋ।

ਸਿੱਟਾ

ਜਦੋਂ ਮੈਂ ਆਪਣੀ ਰਿਪੋਰਟ ਦੀ ਸਮੱਗਰੀ ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ ਆਪਣੇ ਕੰਮ ਦੌਰਾਨ ਇਕੱਠੀ ਕੀਤੀ ਜਾਣਕਾਰੀ ਦੇ ਅਧਾਰ 'ਤੇ ਇਹ ਲੇਖ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਤਾਂ ਮੈਨੂੰ ਉਮੀਦ ਨਹੀਂ ਸੀ ਕਿ ਇਸ ਵਿੱਚ ਇੰਨਾ ਕੁਝ ਹੋਵੇਗਾ। ਹੁਣ, ਜਦੋਂ ਟੈਕਸਟ ਐਡੀਟਰ ਜਿਸ ਵਿੱਚ ਮੈਂ ਇਹ ਲੇਖ ਟਾਈਪ ਕਰ ਰਿਹਾ ਹਾਂ, ਮੈਨੂੰ ਬਦਨਾਮੀ ਨਾਲ ਦੱਸਦਾ ਹੈ ਕਿ ਪੰਨਾ 15 ਚਲਾ ਗਿਆ ਹੈ, ਮੈਂ ਅੰਤਰਿਮ ਨਤੀਜਿਆਂ ਨੂੰ ਸੰਖੇਪ ਕਰਾਂਗਾ। ਹੋਰ ਗੁਰੁਰ, API, ਵਿਜ਼ੂਅਲ ਟੂਲ ਅਤੇ ਨੁਕਸਾਨਾਂ ਨੂੰ ਅਗਲੇ ਲੇਖ ਵਿੱਚ ਕਵਰ ਕੀਤਾ ਜਾਵੇਗਾ।

ਸਿੱਟਾ:

• ਆਧੁਨਿਕ ਪੀਸੀ ਦੇ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਥਰਿੱਡਾਂ, ਅਸਿੰਕ੍ਰੋਨੀ ਅਤੇ ਸਮਾਨਤਾਵਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਸਾਧਨਾਂ ਨੂੰ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ।
• .NET ਕੋਲ ਇਹਨਾਂ ਉਦੇਸ਼ਾਂ ਲਈ ਬਹੁਤ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਟੂਲ ਹਨ
• ਉਹ ਸਾਰੇ ਇੱਕ ਵਾਰ ਵਿੱਚ ਪ੍ਰਗਟ ਨਹੀਂ ਹੋਏ, ਇਸਲਈ ਤੁਸੀਂ ਅਕਸਰ ਵਿਰਾਸਤੀ ਲੱਭ ਸਕਦੇ ਹੋ, ਹਾਲਾਂਕਿ, ਪੁਰਾਣੇ APIs ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਕੋਸ਼ਿਸ਼ ਦੇ ਬਦਲਣ ਦੇ ਤਰੀਕੇ ਹਨ.
• .NET ਵਿੱਚ ਥਰਿੱਡਾਂ ਨਾਲ ਕੰਮ ਕਰਨਾ ਥ੍ਰੈਡ ਅਤੇ ਥ੍ਰੈਡਪੂਲ ਕਲਾਸਾਂ ਦੁਆਰਾ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ
• Thread.Abort, Thread.Interrupt, ਅਤੇ Win32 API TerminateThread ਢੰਗ ਖਤਰਨਾਕ ਹਨ ਅਤੇ ਵਰਤੋਂ ਲਈ ਸਿਫ਼ਾਰਸ਼ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਇਸ ਦੀ ਬਜਾਏ, CancellationToken ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ
• ਪ੍ਰਵਾਹ ਇੱਕ ਕੀਮਤੀ ਸਰੋਤ ਹੈ ਅਤੇ ਇਸਦੀ ਸਪਲਾਈ ਸੀਮਤ ਹੈ। ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਜਿੱਥੇ ਥਰਿੱਡ ਸਮਾਗਮਾਂ ਦੀ ਉਡੀਕ ਵਿੱਚ ਰੁੱਝੇ ਹੋਏ ਹੋਣ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸਦੇ ਲਈ TaskCompletionSource ਕਲਾਸ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੁਵਿਧਾਜਨਕ ਹੈ
• ਸਮਾਨਤਾ ਅਤੇ ਅਸਿੰਕ੍ਰੋਨੀ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਸ਼ਕਤੀਸ਼ਾਲੀ ਅਤੇ ਉੱਨਤ .NET ਟੂਲ ਟਾਸਕ ਹਨ।
• c# async/await ਓਪਰੇਟਰ ਗੈਰ-ਬਲਾਕਿੰਗ ਉਡੀਕ ਦੀ ਧਾਰਨਾ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ
• ਤੁਸੀਂ TaskScheduler ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕਲਾਸਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਥ੍ਰੈਡਾਂ ਵਿੱਚ ਕਾਰਜਾਂ ਦੀ ਵੰਡ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰ ਸਕਦੇ ਹੋ
• ValueTask ਢਾਂਚਾ ਹਾਟ-ਪਾਥਾਂ ਅਤੇ ਮੈਮੋਰੀ-ਟ੍ਰੈਫਿਕ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਵਿੱਚ ਉਪਯੋਗੀ ਹੋ ਸਕਦਾ ਹੈ
• ਵਿਜ਼ੂਅਲ ਸਟੂਡੀਓ ਦੇ ਟਾਸਕ ਅਤੇ ਥ੍ਰੈਡ ਵਿੰਡੋਜ਼ ਮਲਟੀ-ਥ੍ਰੈਡਡ ਜਾਂ ਅਸਿੰਕ੍ਰੋਨਸ ਕੋਡ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੀ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।
• PLinq ਇੱਕ ਵਧੀਆ ਟੂਲ ਹੈ, ਪਰ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਸ ਵਿੱਚ ਤੁਹਾਡੇ ਡੇਟਾ ਸਰੋਤ ਬਾਰੇ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਨਾ ਹੋਵੇ, ਪਰ ਇਸਨੂੰ ਵਿਭਾਗੀਕਰਨ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
• ਨੂੰ ਜਾਰੀ ਰੱਖਿਆ ਜਾਵੇਗਾ…

ਸਰੋਤ: www.habr.com