@synchronized lock / unlock ใน Objective-C ทำอย่างไร

@ ซิงโครไนซ์ไม่ได้ใช้ "ล็อค" และ "ปลดล็อค" เพื่อให้เกิดการยกเว้นซึ่งกันและกันหรือไม่? มันล็อค / ปลดล็อกได้อย่างไร

ผลลัพธ์ของโปรแกรมต่อไปนี้เป็น "Hello World" เท่านั้น

@interface MyLock: NSLock<NSLocking>
@end

@implementation MyLock

- (id)init {
    return [super init];
}

- (void)lock {
    NSLog(@"before lock");
    [super lock];
    NSLog(@"after lock");
}

- (void)unlock {
    NSLog(@"before unlock");
    [super unlock];
    NSLog(@"after unlock");
}

@end


int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    MyLock *lock = [[MyLock new] autorelease];
    @synchronized(lock) {
        NSLog(@"Hello World");
    }

    [pool drain];
}

การซิงโครไนซ์ระดับภาษา Objective-C ใช้ mutex เช่นเดียวกับที่NSLockทำ ความหมายมีความแตกต่างทางเทคนิคเล็กน้อย แต่โดยทั่วไปแล้วมันถูกต้องที่จะคิดว่ามันเป็นสองอินเตอร์เฟสที่แยกจากกันซึ่งถูกนำมาใช้บนเอนทิตี้ทั่วไป (ดั้งเดิมมากกว่า)

โดยเฉพาะอย่างยิ่งกับNSLockคุณมีการล็อคอย่างชัดเจนในขณะที่@synchronizedคุณมีการล็อคโดยนัยที่เกี่ยวข้องกับวัตถุที่คุณใช้ในการประสาน ประโยชน์ของการล็อคระดับภาษาคือคอมไพเลอร์เข้าใจดีว่ามันสามารถจัดการกับปัญหาการกำหนดขอบเขต แต่โดยทั่วไปแล้วพวกเขาจะทำงานเหมือนกัน

คุณคิดว่า@synchronizedคอมไพเลอร์เขียนใหม่:

- (NSString *)myString {
  @synchronized(self) {
    return [[myString retain] autorelease];
  }
}

เปลี่ยนเป็น:

- (NSString *)myString {
  NSString *retval = nil;
  pthread_mutex_t *self_mutex = LOOK_UP_MUTEX(self);
  pthread_mutex_lock(self_mutex);
  retval = [[myString retain] autorelease];
  pthread_mutex_unlock(self_mutex);
  return retval;
}

ไม่ถูกต้องเนื่องจากการแปลงจริงมีความซับซ้อนมากขึ้นและใช้การล็อคแบบเรียกซ้ำ แต่ควรได้รับการข้าม

ใน Objective-C @synchronizedบล็อกจะจัดการกับการล็อกและปลดล็อค (รวมถึงข้อยกเว้นที่เป็นไปได้) โดยอัตโนมัติสำหรับคุณ รันไทม์สร้าง NSRecursiveLock แบบไดนามิกที่เกี่ยวข้องกับวัตถุที่คุณซิงโครไนซ์ เอกสารประกอบของ Apple นี้อธิบายรายละเอียดเพิ่มเติม นี่คือเหตุผลที่คุณไม่เห็นข้อความบันทึกจากคลาสย่อย NSLock ของคุณวัตถุที่คุณซิงโครไนซ์จะเป็นอะไรก็ได้ไม่ใช่แค่ NSLock

โดยพื้นฐานแล้ว@synchronized (...)โครงสร้างความสะดวกสบายที่ปรับปรุงรหัสของคุณ เช่นเดียวกับ abstractions ที่ทำให้เข้าใจง่ายที่สุดมันเกี่ยวข้องกับค่าใช้จ่าย (คิดว่ามันเป็นค่าใช้จ่ายแอบแฝง) และเป็นเรื่องดีที่ควรระวัง แต่ประสิทธิภาพดิบอาจไม่ใช่เป้าหมายสูงสุดเมื่อใช้โครงสร้างดังกล่าวแล้ว

แท้จริง

{
  @synchronized(self) {
    return [[myString retain] autorelease];
  }
}

เปลี่ยนเป็นโดยตรง:

// needs #import <objc/objc-sync.h>
{
  objc_sync_enter(self)
    id retVal = [[myString retain] autorelease];
  objc_sync_exit(self);
  return retVal;
}

API นี้มีให้ตั้งแต่ iOS 2.0 และนำเข้าโดยใช้ ...

#import <objc/objc-sync.h>

การดำเนินงานของ Apple @synchronized เปิดแหล่งที่มาและมันสามารถพบได้ที่นี่ Mike ash เขียนบทความสองเรื่องที่น่าสนใจเกี่ยวกับเรื่องนี้:

• ล็อคความปลอดภัยของด้ายและรวดเร็ว
• มาสร้าง @ ซิงโครไนซ์กันเถอะ

สรุปมันมีตารางที่แมปตัวชี้วัตถุ (ใช้ที่อยู่หน่วยความจำของพวกเขาเป็นกุญแจ) เพื่อpthread_mutex_tล็อคซึ่งจะถูกล็อคและปลดล็อคตามความจำเป็น

เป็นเพียงการเชื่อมโยงสัญญาณกับทุกวัตถุและใช้สิ่งนั้น