in C++ , thread safe singleton class is almost written by double checked
locking style.
(more imfomation about this, see 'pattern hatching' wriiten by John Vlissides)

in D , at first I wrote following program.

----------------------------------------------------------------
template singleton(T) { class singleton {
public:
static T get() {
if (!t) {
synchronized {
if (!t) t = new T;
}
}
return t;
}
private:
static T t;
}}
----------------------------------------------------------------
but I can't guess whether it works well or not.
double-checked locking is the idiom that should never be used in Java.

for more imfomation about this: http://www-106.ibm.com/developerworks/java/library/j-dcl.html?dwzone=java

I want to know whether double checked locking is valid or not in D.

yaneurao.

I doubt it.

That's one of the reasons why making singletons is not a simple thing. (Since D has modules, I tend to agree with Sean that they're not really needed anyway.)

"yaneurao" <yaneurao_member@pathlink.com> wrote in message news:bud0lr$1ekq$1@digitaldaemon.com...
> in C++ , thread safe singleton class is almost written by double checked
> locking style.
> (more imfomation about this, see 'pattern hatching' wriiten by John
Vlissides)
>
> in D , at first I wrote following program.
>
> ----------------------------------------------------------------
> template singleton(T) { class singleton {
> public:
> static T get() {
> if (!t) {
> synchronized {
> if (!t) t = new T;
> }
> }
> return t;
> }
> private:
> static T t;
> }}
> ----------------------------------------------------------------
> but I can't guess whether it works well or not.
> double-checked locking is the idiom that should never be used in Java.
>
> for more imfomation about this: http://www-106.ibm.com/developerworks/java/library/j-dcl.html?dwzone=java
>
> I want to know whether double checked locking is valid or not in D.
>
> yaneurao.
>
>

This might be related to the current discussion about auto object creation syntax.

Although I suppose these guys have one point... one of the purposes of singletons is to allow third parties to inject code into the system by deriving from the singleton base... for that reason, point of instantiation should be left out of the base so that it may be created by the client (unless you can get the base class to know enough about the derived class, e.g. the strangely recursive inheritance pattern).

There isn't a way to accomplish that (easily) with the module system aside from public import.  But once you have that, you start having a kind of one instance, semi-extendable kind of class/object combination, which almost exactly fits the definition of singleton.

Every C++ singleton implementation I've seen has had problems though... it's as if the language somehow goes out of its way to make that kind of thing difficult.  Personally I blame the loose linking / inter-module initialization order standards.  Also compilers tend to strip out isolated global objects that are never used by anything, so you cannot for instance put your program entry point inside a global object ctor.  If it weren't for that, global object ctors/dtors would be a good way to write module init/shutdown code.

It seems to me that if the module system is in fact intended to supercede the concept of singleton, that it should provide the capacity for public import and it should do this kind of thread-safety automatically.

Or maybe use of the synchronized keyword, as in:

synchronized module mysingleton;

Or maybe

synchronized static this() { ... }

Sean

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bud3a3$1ik1$1@digitaldaemon.com...
> I doubt it.
>
> That's one of the reasons why making singletons is not a simple thing. (Since D has modules, I tend to agree with Sean that they're not really needed anyway.)
>
> "yaneurao" <yaneurao_member@pathlink.com> wrote in message news:bud0lr$1ekq$1@digitaldaemon.com...
> > in C++ , thread safe singleton class is almost written by double checked
> > locking style.
> > (more imfomation about this, see 'pattern hatching' wriiten by John
> Vlissides)