If a synchronized method call sees that someone's already partying with its object, it waits. So far so good. Now here's something I don't quite get: if a *const* synchronized method call sees that another const synchronized method call is holding the lock, then why it needs to be held up? D features deep const; that's a promise strong enough to drop the sync'ing, no?

Example:

import std.stdio;
import core.thread;

shared class K {
    string value;

    this (string value) {
        this.value = value;
    }

    synchronized void metoda() const {
        foreach (i; 0..3) {
            writeln(Thread.getThis().name, " is calling metoda. My value is ", value);
            Thread.sleep(1_000_000);
        }
    }
}

class My_Thread : Thread {
    K k;

    this(K k, string name) {
        super(&run);
        this.k = k;
        this.name = name;
    }

    void run() {
        k.metoda();
    }
}

void main() {
    K k = new K("some value");
    (new My_Thread(k, "Thread 1")).start();
    (new My_Thread(k, "Thread 2")).start();
}


Now, sync'ing would be necessary if one of the threads could mutate K, but here?

The output is:

Thread 1 is calling metoda. My value is some value
Thread 1 is calling metoda. My value is some value
Thread 1 is calling metoda. My value is some value
Thread 2 is calling metoda. My value is some value
Thread 2 is calling metoda. My value is some value
Thread 2 is calling metoda. My value is some value


Tomek

immutable means "no one can modify this."

const means "someone might be able to modify this, but not you can't."

Daniel Keep wrote:
> immutable means "no one can modify this."
> 
> const means "someone might be able to modify this, but not you can't."

	So?

	Basically, what the OP said, is that we need readers-writer locks
[1]. A const synchronized method would use the read lock (and
therefore several threads can access the same object through *const*
synchronized methods simultaneously), but a non const synchronized
method would use the read-write lock (which would prevent anyone
else from accessing the same object through a synchronized method,
be it const or not).

		Jerome

[1] http://en.wikipedia.org/wiki/Readers-writer_lock
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Dnia 12-06-2010 o 09:28:58 Jérôme M. Berger <jeberger@free.fr> napisał(a):

> Daniel Keep wrote:
>> immutable means "no one can modify this."
>>
>> const means "someone might be able to modify this, but not you can't."
>
> 	So?
>
> 	Basically, what the OP said, is that we need readers-writer locks
> [1]. A const synchronized method would use the read lock (and
> therefore several threads can access the same object through *const*
> synchronized methods simultaneously), but a non const synchronized
> method would use the read-write lock (which would prevent anyone
> else from accessing the same object through a synchronized method,
> be it const or not).
>
> 		Jerome
>
> [1] http://en.wikipedia.org/wiki/Readers-writer_lock

Exactly.

How is synchronization implemented in D right now? Would there be room to let the lock distinguish reads & writes?


Tomek