6 ms·
I tried: Question/Task: Write a lock implementation in Rust I got this (lol): use std::sync::Mutex; struct Lock { mutex: Mutex<()>, }
by devnull3 3y ago
I tried:
Question/Task: Write a lock implementation in Rust
I got this (lol):
use std::sync::Mutex;
struct Lock {
mutex: Mutex<()>,
}
impl Lock {
fn new() -> Lock {
Lock {
mutex: Mutex::new(()),
}
}
fn lock(&self) -> MutexGuard<()> {
self.mutex.lock().unwrap()
}
fn unlock(&self) {
self.mutex.unlock();
}
}
- mden 3y agoI mean, it's not really wrong, is it? :D Have you tried the same with gpt4?
- int_19h 3y agoGPT-4 also reaches out for Mutex. Which I think is fair - it really is the easiest way to solve the literal problem presented to it, after all. OTOH given "write a lock implementation in Rust without using existing standard library synchronization primitives", both try to implement a spinlock. But GPT-4 knows about compare_and_swap, whereas Bard appears to believe that spinning on load(SeqCst) followed by store(SeqCst) is sufficient to synchronize with other threads. But a task like that is more likely to depend at how much Rust code each model was trained on rather than its capability to reason.