On Sun, Oct 07, 2007 at 10:57:31AM -0700, Walter Bright wrote:
> David Brown wrote:
>>   - 'pause/resume' is not a useful thread primitive.  As we've seen by
>>   sample code, just doing simple things is dreadfully difficult, and
>>   very easy to get wrong, having deadlocks, starvation, and other
>>   issues.
>
> The main reason for the existence of pause/resume is so the garbage collector can pause all the threads, do a gc sweep, then resume them.

I don't think they should go away :-)  I just think there needs to be
something else to use for synchronization.  Just because it is possible to
synchronize with pause/resume, doesn't mean one should.

David

David Brown wrote:
> On Sun, Oct 07, 2007 at 10:57:31AM -0700, Walter Bright wrote:
>> David Brown wrote:
>>>   - 'pause/resume' is not a useful thread primitive.  As we've seen by
>>>   sample code, just doing simple things is dreadfully difficult, and
>>>   very easy to get wrong, having deadlocks, starvation, and other
>>>   issues.
>>
>> The main reason for the existence of pause/resume is so the garbage collector can pause all the threads, do a gc sweep, then resume them.
> 
> I don't think they should go away :-)  I just think there needs to be
> something else to use for synchronization.  Just because it is possible to
> synchronize with pause/resume, doesn't mean one should.

It never occurred to me that someone would use pause/resume for syncing. I thought the concepts were orthogonal.

"Walter Bright" <newshound1@digitalmars.com> wrote in message
> It never occurred to me that someone would use pause/resume for syncing. I thought the concepts were orthogonal.

People will (ab)use whatever is made visible <g>
That's why Tango hides pause/resume

Walter Bright wrote:
> David Brown wrote:
>> On Sun, Oct 07, 2007 at 10:57:31AM -0700, Walter Bright wrote:
>>> David Brown wrote:
>>>>   - 'pause/resume' is not a useful thread primitive.  As we've seen by
>>>>   sample code, just doing simple things is dreadfully difficult, and
>>>>   very easy to get wrong, having deadlocks, starvation, and other
>>>>   issues.
>>>
>>> The main reason for the existence of pause/resume is so the garbage collector can pause all the threads, do a gc sweep, then resume them.
>>
>> I don't think they should go away :-)  I just think there needs to be
>> something else to use for synchronization.  Just because it is possible to
>> synchronize with pause/resume, doesn't mean one should.
> 
> It never occurred to me that someone would use pause/resume for syncing. I thought the concepts were orthogonal.

For what it's worth, Java has pause/resume as deprecated members of its Thread class.  I suspect they originally included them for garbage collection as well, and deprecated them when people started using them for synchronization (they're a fantastic way to deadlock an app).  Doug Lea's containers and such use them, for example, because Java does not offer standalone mutexes, semaphores, etc.


Sean

Walter Bright wrote:
> Sean Kelly wrote:
>> For what it's worth, Tango will never choose to run exclusively on the Phobos runtime.  One of the primary reasons many people choose Tango is for its threading package, and this is a runtime feature.  Therefore, dropping this package to use the Phobos version would be foolish, and I suspect that it would leave a number of Tango users (some developing professional software) in a bit of a lurch.
> 
> The threading package in Phobos is not very good, as it is based on my very poor understanding of the problem. Drop kicking std.thread is certainly open for discussion for v2. I wouldn't shed a tear for it <g>.

Works for me :-)


Sean

David Brown wrote:
> 
> As I've said before, Phobos should contains a small set of easy to use
> primitives that are efficiently implemented on the underlying OS.  This is
> not currently the case.

Tango offers the following:

Mutex
Barrier
Condition
Semaphore
ReadWriteMutex

In addition, Mutex and ReadWriteMutex work with the 'synchronized' statement.

Assuming the Tango and Phobos runtime libraries somehow merge for D 2.0,  these would likely either be included or would at least be compatible with Phobos.

> Aside from that, it would be useful to have a set of higher-level
> synchronization operations, such as bounded and unbounded buffers,
> implemented on top of this that are also part of a common library.

More is planned for Tango and largely waiting for the time to work on it.  Demand is also a factor.  If there's a pressing need for something, it's more likely to work its way to the top of my list.

I'd actually created a thread pool of sorts and then stalled when I started thinking about how to perform object cleanup.  I expect to pick it back up again soon though.


Sean

"Jascha Wetzel" <firstname@mainia.de> wrote in message news:fe63ji$10r2$1@digitalmars.com...
> Walter Bright wrote:
>> Bug fixes. New (and very modest) C++ interface. Library module overhauls by Andrei Alexandrescu. Brad Roberts is working behind the curtain to get phobos development much better organized.
>>
>> http://www.digitalmars.com/d/1.0/changelog.html
>> http://ftp.digitalmars.com/dmd.1.022.zip
>>
>> http://www.digitalmars.com/d/changelog.html
>> http://ftp.digitalmars.com/dmd.2.005.zip
>
> neat!
> maybe the docs for c++ interfacing should mention, that it requires a compatible c++ compiler to work (DMC or MSVC on windows and GCC 3.x on linux?).

I don't think MSVC will work.  Only DMC.  Or am I wrong?

-Craig 

Craig Black wrote:
> 
> "Jascha Wetzel" <firstname@mainia.de> wrote in message news:fe63ji$10r2$1@digitalmars.com...
>> maybe the docs for c++ interfacing should mention, that it requires a compatible c++ compiler to work (DMC or MSVC on windows and GCC 3.x on linux?).
> 
> I don't think MSVC will work.  Only DMC.  Or am I wrong?

It does follow MSVC's name mangling scheme and function interface. It should work with MSVC compile C++ DLLs.

Walter Bright pisze:
> Craig Black wrote:
>>
>> "Jascha Wetzel" <firstname@mainia.de> wrote in message news:fe63ji$10r2$1@digitalmars.com...
>>> maybe the docs for c++ interfacing should mention, that it requires a compatible c++ compiler to work (DMC or MSVC on windows and GCC 3.x on linux?).
>>
>> I don't think MSVC will work.  Only DMC.  Or am I wrong?
> 
> It does follow MSVC's name mangling scheme and function interface. It should work with MSVC compile C++ DLLs.

I just wonder if it wouldn't be better to allow external plugins for DMD. This way you could just create different plugins to allow different name mangling and different interpretation of data in extern() sections...

We could have then different plugins written by external vendors eg:
CPP_GCC
CPP_MSVC
Pascal
etc.

Walter, did you think about solution like this? Is there possibility to implement this?

Regards
Marcin Kuszczak
(aarti_pl)

Aarti_pl pisze:
> I just wonder if it wouldn't be better to allow external plugins for DMD. This way you could just create different plugins to allow different name mangling and different interpretation of data in extern() sections...
> 
> We could have then different plugins written by external vendors eg:
> CPP_GCC
> CPP_MSVC
> Pascal
> etc.
> 
> Walter, did you think about solution like this? Is there possibility to implement this?
> 
> Regards
> Marcin Kuszczak
> (aarti_pl)

BTW: Word plugins is used in 2.0 changelog, when mentioning about C++ interface, but *probably* in other meaning...

It would be nice to see real plugins for D compiler...

BR
Marcin Kuszczak
(aarti_pl)