Just started having a look at D...

I can't seem to find anything about synchronizing the actions of threads - something along the lines of a pthread 'condition' variable which can be waited on or signalled. Are we supposed to make use of the underlying thread library of our choice? ie. actually use a 'pthread_cond_t', initialising and using it manually?

Are there plans for extending the 'synchronized' interface so that it can be specified to be a read only syncronization allowing multiple threads to access read-only data simultaneously?

And just in case the above has been debated to death already, whats the recomended method for performing a search on the contents of this forum?

Suxx

> I can't seem to find anything about synchronizing the actions of threads - something along the lines of a pthread 'condition' variable which can be
waited
> on or signalled. Are we supposed to make use of the underlying thread
library of
> our choice? ie. actually use a 'pthread_cond_t', initialising and using it manually?
>
> Are there plans for extending the 'synchronized' interface so that it can
be
> specified to be a read only syncronization allowing multiple threads to
access
> read-only data simultaneously?
>
> And just in case the above has been debated to death already, whats the recomended method for performing a search on the contents of this forum?
>

Well, the best thing is to read the reference manual of D. I can't blame you for not noticing the synchronize{ } statement there, cause I haven't noticed 0b literals either while I was reading it :-)

Just read the manual again carefuly :-)

As reading my post should make clear, you will note that I have seen and read
the manual and read the section on 'synchronize'.
The question I asked was not 'how do I prevent multiple threads running the same
code at the same time?' which is what the 'syncronized' statement is for.
My question was 'how do I syncronize the action of threads?' - if not in those
exact words. By this I mean something along the lines of being able to tell
ThreadA to suspend execution until Thread[B,C,D,...] completes some task and
signals completion?

I haven't tried but from the documentation in http://www.digitalmars.com/d/phobos.html you can do:

myThread.wait();

void wait();
    Wait for this thread to terminate. Throws ThreadError if the thread
hasn't begun yet or has already terminated or is called on itself.

void wait(unsigned milliseconds);
    Wait for this thread to terminate or until milliseconds time has
elapsed, whichever occurs first. Throws ThreadError if the thread hasn't
begun yet or has already terminated or is called on itself.



<suxx@myrealbox.com> wrote in message news:bk9ori$25q3$1@digitaldaemon.com...
> Just started having a look at D...
>
> I can't seem to find anything about synchronizing the actions of threads - something along the lines of a pthread 'condition' variable which can be
waited
> on or signalled. Are we supposed to make use of the underlying thread
library of
> our choice? ie. actually use a 'pthread_cond_t', initialising and using it manually?
>
> Are there plans for extending the 'synchronized' interface so that it can
be
> specified to be a read only syncronization allowing multiple threads to
access
> read-only data simultaneously?
>
> And just in case the above has been debated to death already, whats the recomended method for performing a search on the contents of this forum?
>
> Suxx

top

Given the answers so far, can I assume that someone (walter maybe) is looking into a few more threading primitives? Or is it an open field with suggestions/requirements/patches welcome from all comers?

Suxx

I am a new starter with D too.  Like you, I am looking for something that
allows useful inter-thread cooperation.

> I can't seem to find anything about synchronizing the actions of threads -
> something along the lines of a pthread 'condition' variable which can be waited
> on or signalled. Are we supposed to make use of the underlying thread library of
> our choice? ie. actually use a 'pthread_cond_t', initialising and using it
> manually?

What you are describing here is along the lines of the "entry" feature
in Ada95 protected objects, which uses a condition vaiable as you describe, with
a syntax that would look a bit like this in D:

public synchronized void removeFromQueue(...) provided itemCount > 0 {
  ...
}

The idea being that a thread trying to execute this method would
not only have to be the only thread in the object, but the condition
(in this case itemCount > 0) would have to be true too.

Some other thread could eventually make the condition true by making
a different synchronized call.


> Are there plans for extending the 'synchronized' interface so that it can be
> specified to be a read only syncronization allowing multiple threads to access
> read-only data simultaneously?

I would like to see something high-level like my suggestion above, rather than
the Java approach of adding wait() and notify() methods in Object.
The Java approach is more difficult for the coder to get right, but even
that would be a whole lot better than nothing.


> And just in case the above has been debated to death already, whats the
> recomended method for performing a search on the contents of this forum?

<suxx@myrealbox.com> wrote in message news:bkaiuk$adp$1@digitaldaemon.com...
> Given the answers so far, can I assume that someone (walter maybe) is
looking
> into a few more threading primitives? Or is it an open field with suggestions/requirements/patches welcome from all comers?

Yes. I am not an expert in threading applications. I've made a stab at it with synchronized and with the functions in std.thread. If you'd like to contribute improvements, by all means!

We are about to embark on a long threading/multiprocessor nightmare with Playstation3 and Xbox 2.  I hope we can figure out a way to make it easy.

I was thinking more that you'd make a subclass of thread and override the run method to call your function.  But thread.d seems pretty sophisticated to me.  Has all the features I would want.  But I'm no expert either.

You could also store the thread object pointer somewhere in thread local storage instead of having to look it up in a table.  But then you couldn't easily support pauseall etc.

I'm wondering how come class thread doesn't have a destructor that calls wait()?  Is it likely that you would want to allow a thread to continue running after its thread object has been destroyed?

The wait() functions do not set the thread state to TS.TERMINATED

Also I can't see why you would possibly want to make a thread object without actually starting it.  So I would have the ctors call start automatically and make start a private function.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:bqmtfe$2p49$1@digitaldaemon.com...
>
> <suxx@myrealbox.com> wrote in message
news:bkaiuk$adp$1@digitaldaemon.com...
> > Given the answers so far, can I assume that someone (walter maybe) is
> looking
> > into a few more threading primitives? Or is it an open field with suggestions/requirements/patches welcome from all comers?
>
> Yes. I am not an expert in threading applications. I've made a stab at it with synchronized and with the functions in std.thread. If you'd like to contribute improvements, by all means!

Sean L. Palmer wrote:

>Also I can't see why you would possibly want to make a thread object without
>actually starting it.  So I would have the ctors call start automatically
>and make start a private function.
>
>Sean
>
>  
>
I think programmers should be able to choose between creating a running thread and a dormant one. Though I am sure you are right that creating a thread and never starting it is foolhardy. I can't think of an example, but I'm sure someone some where might have a reason to delay the starting of a thread.

Perhaps a thread that is started automatically by the constructor would have a non-deterministic start time, thus making benchmarks in accurate, though perhaps that could be overcome by the use of a subclassed thread type that took care of its own timing...

Alix...

-- 
           Alix Pexton
Webmaster - http://www.theDjournal.com

           Alix@theDjournal.com

Alix Pexton wrote:
> I think programmers should be able to choose between creating a running thread and a dormant one. Though I am sure you are right that creating a thread and never starting it is foolhardy. I can't think of an example, but I'm sure someone some where might have a reason to delay the starting of a thread.

One example, hold the cheese, coming right up!

A non-started thread object could be used for passing long-running algorithms to another object. For example, you could pass a bunch of dormant image-filtering threads to some kind of "run all these filters on that image" function. You could also pass delegates and have the function create the threads, but sometimes it can be easier to use ready-made thread objects. For example, if the filters are to be run concurrently with different priorities then you can pre-configure the thread objects before passing them to that function.

Oh, speaking of pre-configuring: another example. Maybe you have to set some parameters before the thread is started. For example, for an "idle" priority thread, you'd probably want to change the priority first, before the thread is started.

Hauke