December 04, 2003
You don't have accurate timing with threads anyway, or at least you shouldn't rely on it.

You could always just not make the thread object til you need it to start.

I don't like how the current implementation adds extra wordiness, forces you to jump through a few extra hoops just to get the "normal" usage behavior.

Sean

"Alix Pexton" <Alix@thedjournal.com> wrote in message news:bqn3kd$dg$1@digitaldaemon.com...
> 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.
>
> 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...


December 04, 2003
"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bqnppo$109o$1@digitaldaemon.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.

Ok, maybe a good one, but you could pass in a delegate and priority, instead, as you say.

> 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.

So make a constructor that takes the priority as a parameter. (default parameter would be better, but isn't D)

I just don't want to baggage the common case by the exceptional case.

Sean


December 04, 2003
Sean L. Palmer wrote:
>>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.
> 
> 
> So make a constructor that takes the priority as a parameter. (default
> parameter would be better, but isn't D)

But what if it gets more complicated? What if you want the thread to be part of a thread group? What if you have to manually allocate TLS space for the thread because your OS doesn't provide any?

> I just don't want to baggage the common case by the exceptional case.

That's easy to solve. Just add a boolean (errr, I mean "bit") argument startNow=true to the constructor. That allows you to use it both ways, but the default case is to simply start it right away...

Hauke

December 04, 2003
"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bqo1de$1bpp$1@digitaldaemon.com...
> Sean L. Palmer wrote:
> >>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.
> >
> >
> > So make a constructor that takes the priority as a parameter. (default parameter would be better, but isn't D)
>
> But what if it gets more complicated? What if you want the thread to be part of a thread group? What if you have to manually allocate TLS space for the thread because your OS doesn't provide any?

The library should guarantee you a certain minimal level of functionality. This should fall under the category of "implementation detail".

> > I just don't want to baggage the common case by the exceptional case.
>
> That's easy to solve. Just add a boolean (errr, I mean "bit") argument startNow=true to the constructor. That allows you to use it both ways, but the default case is to simply start it right away...

Sure.  ;)

Now if dtor can be made to wait for the thread to shut down, we can do this:

void dowork()
{
    auto thread worker1,worker2;
    worker1 = new thread(doworkA);
    worker2 = new thread(doworkB);
}

And before dowork is finished, you can be sure that all the work is complete.

Sean


February 06, 2004
Walter wrote:
> 
> 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!

Are the library features implemented in C/C++?  I'm still getting up to speed on D but Boost has a decent condvar implementation that might be workable if this is true.

Sean

February 07, 2004
"Sean Kelly" <sean@ffwd.cx> wrote in message news:bvuoh2$1hbo$1@digitaldaemon.com...
> Walter wrote:
> >
> > 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!
>
> Are the library features implemented in C/C++?  I'm still getting up to speed on D but Boost has a decent condvar implementation that might be workable if this is true.

No, they're in D!


February 07, 2004
Walter wrote:
> "Sean Kelly" <sean@ffwd.cx> wrote in message
> news:bvuoh2$1hbo$1@digitaldaemon.com...
>
>>>with synchronized and with the functions in std.thread. If you'd like to
>>>contribute improvements, by all means!
>>
>>Are the library features implemented in C/C++?  I'm still getting up to
>>speed on D but Boost has a decent condvar implementation that might be
>>workable if this is true.
> 
> No, they're in D!

So say I wanted to work on new synchronization methods, this would be changes to the compiler and not Phobos?

Sean

February 07, 2004
Sean Kelly wrote:
>
> So say I wanted to work on new synchronization methods, this would be changes to the compiler and not Phobos?

Er, clarification.  I meant to ask whether the thread implementation compiles directly or if it ties back to platform library calls on the operating system.  Like is there a thread implementation file somewhere calling the Win32 _beginthread function?


Sean

February 07, 2004
Sean Kelly wrote:
>
> Er, clarification.  I meant to ask whether the thread implementation compiles directly or if it ties back to platform library calls on the operating system.  Like is there a thread implementation file somewhere calling the Win32 _beginthread function?

Answered my own question.  Next time I'll just look at the Phobos source before asking :)  So it's in D but ultimately makes Win32 or pthread platofmr calls.


Sean

1 2
Next ›   Last »