الاختلافات بين Go Playground والجهاز المحلي

عند تشغيل تعليمات برمجية على Go Playground، قد يواجه المطورون اختلافات مقارنة بتشغيل نفس التعليمات البرمجية على أجهزتهم المحلية. تستكشف هذه المقالة الاختلافات السلوكية، خاصة عند التعامل مع goroutines وآليات المزامنة.

دراسة حالة: سلوك الكود في Go Playground مقابل Local Machine

ضع في اعتبارك كود Go التالي:

package main

import (
    "fmt"
)

func other(done chan bool) {
    done في ساحة اللعب Go، ينتج عن هذا الرمز خطأ: "استغرقت العملية وقتًا طويلاً." يشير هذا إلى أن goroutine الذي تم إنشاؤه داخل الوظيفة الأخرى يعمل إلى أجل غير مسمى. 
 
 ومع ذلك، فإن تشغيل نفس الكود على جهاز محلي به مراكز وحدة معالجة مركزية متعددة (GOMAXPROCS > 1) يؤدي إلى المخرجات التالية:
Hello, playground
Finished.
هذا يعني أن goroutine الذي تم إنشاؤه داخل الآخرين ينتهي عند انتهاء goroutine الرئيسي.
شرح الفجوة السلوكية
السلوك المختلف بين ملعب Go والجهاز المحلي يمكن أن يعزى إلى عدد المعالجات المتاحة. في ساحة لعب Go، يكون الإعداد الافتراضي لـ GOMAXPROCS هو 1، مما يعني أنه لا يمكن تشغيل سوى goroutine واحد في المرة الواحدة. لذلك، في المثال أعلاه، يمنع goroutine الذي لا نهاية له والذي تم إنشاؤه داخل أخرى، goroutine الرئيسي من الاستمرار.
 في المقابل، عند التشغيل محليًا باستخدام عدة نوى لوحدة المعالجة المركزية، فإن GOMAXPROCS يضبط افتراضيًا عدد النوى المتاحة، مما يسمح لـ goroutines المتعددة بإجراء تشغيل بشكل متزامن. وبالتالي، فإن goroutine الذي لا نهاية له والذي تم إنشاؤه داخل أخرى لا يمنع goroutine الرئيسي من الخروج. 
 
 الاستنتاج 
 
 يعتمد سلوك goroutines في Go على عدد المعالجات المتاحة (GOMAXPROCS). بينما يستخدم ملعب Go قيمة افتراضية تبلغ 1 والتي يمكن أن تؤدي إلى إدراك أن goroutines تعمل إلى أجل غير مسمى، فإن تشغيل نفس الكود على جهاز محلي متعدد النوى يوفر سلوكًا مختلفًا حيث قد تنتهي goroutines عند انتهاء goroutine الرئيسي. يساعد هذا الفهم المطورين على تجنب سوء الفهم ويضمن أن تتصرف التعليمات البرمجية الخاصة بهم كما هو متوقع في بيئات مختلفة.