Threading Questions
Hey, I've got a few questions if anybody's got a minute. I'm trying to wrap my head around the threading situation in D. So far, things seem to be working as expected, but I want to verify my solutions. 1) Are the following two snippets exactly equivalent(not just in observable behaviour)? a) Mutex mut; mut.lock(); scope(exit) mut.unlock(); b) Mutex mut; synchronized(mut) { } Will 'synchronized' call 'lock' on the Mutex, or do something else(possibly related to the interface Object.Monitor)? 2) Phobos has 'Condition' which takes a Mutex in the constructor. The documentation doesn't exactly specify this, but should I assume it works the same as std::condition_variable in C++? For example, is this correct? Mutex mut; Condition cond = new Condition(mut); // mut must be locked before calling Condition.wait synchronized(mut) // depends on answer to (1) { // wait() unlocks the mutex and enters wait state // wait() must re-acquire the mutex before returning when cond is signalled cond.wait(); } 3) Why do I have to pass a "Mutex" to "Condition"? Why can't I just pass an "Object"? 4) Will D's Condition ever experience spurious wakeups? 5) Why doesn't D's Condition.wait take a predicate? I assume this is because the answer to (4) is no. 6) Does 'shared' actually have any effect on non-global variables beside the syntactic regulations? I know that all global variables are TLS unless explicitly marked as 'shared', but someone once told me something about 'shared' affecting member variables in that accessing them from a separate thread would return T.init instead of the actual value... or something like that. This seems to be wrong(thankfully). For example, I have created this simple Worker class which seems to work fine without a 'shared' keyword in sight(thankfully). I'm wondering though, if there would be any unexpected consequences of doing things this way. http://dpaste.com/2ZG2QZV Thanks! Bit
Re: Threading Questions
Pretty please? :)
Re: Threading Questions
Sorry I don't know the answers but these questions are interesting so BUMP ;) On Friday, 25 September 2015 at 15:19:27 UTC, bitwise wrote: 1) Are the following two snippets exactly equivalent(not just in observable behaviour)? a) Mutex mut; mut.lock(); scope(exit) mut.unlock(); b) Mutex mut; synchronized(mut) { } Will 'synchronized' call 'lock' on the Mutex, or do something else(possibly related to the interface Object.Monitor)? Don't know. Is this Object monitor a mutex or something else? 6) Does 'shared' actually have any effect on non-global variables beside the syntactic regulations? Don't think so.
Re: Threading Questions
I hadn't answered as I do not have answers to the questions you ask. My reason: people should not be doing their codes using these low-level shared memory techniques. Data parallel things should be using the std.parallelism module. Dataflow-style things should be using spawn and channels – akin to the way you do things in Go. So to give you an answer I would go back a stage, forget threads, mutexes, synchronized, etc. and ask what do you want you workers to do? If they are to do something and return a result then spawn and channel is exactly the right abstraction to use. Think "farmer–worker", the farmer spawns the workers and then collects their results. No shared memory anywyere – at least not mutable. On Fri, 2015-09-25 at 15:19 +, bitwise via Digitalmars-d-learn wrote: > Hey, I've got a few questions if anybody's got a minute. > > I'm trying to wrap my head around the threading situation in D. > So far, things seem to be working as expected, but I want to > verify my solutions. > > 1) Are the following two snippets exactly equivalent(not just in > observable behaviour)? > a) > > Mutex mut; > mut.lock(); > scope(exit) mut.unlock(); > > b) > Mutex mut; > synchronized(mut) { } > > Will 'synchronized' call 'lock' on the Mutex, or do something > else(possibly related to the interface Object.Monitor)? > > 2) Phobos has 'Condition' which takes a Mutex in the constructor. > The documentation doesn't exactly specify this, but should I > assume it works the same as std::condition_variable in C++? > > For example, is this correct? > > Mutex mut; > Condition cond = new Condition(mut); > > // mut must be locked before calling Condition.wait > synchronized(mut) // depends on answer to (1) > { > // wait() unlocks the mutex and enters wait state > // wait() must re-acquire the mutex before returning when > cond is signalled > cond.wait(); > } > > 3) Why do I have to pass a "Mutex" to "Condition"? Why can't I > just pass an "Object"? > > 4) Will D's Condition ever experience spurious wakeups? > > 5) Why doesn't D's Condition.wait take a predicate? I assume this > is because the answer to (4) is no. > > 6) Does 'shared' actually have any effect on non-global variables > beside the syntactic regulations? > > I know that all global variables are TLS unless explicitly marked > as 'shared', but someone once told me something about 'shared' > affecting member variables in that accessing them from a separate > thread would return T.init instead of the actual value... or > something like that. This seems to be wrong(thankfully). > > For example, I have created this simple Worker class which seems > to work fine without a 'shared' keyword in sight(thankfully). I'm > wondering though, if there would be any unexpected consequences > of doing things this way. > > http://dpaste.com/2ZG2QZV > > > > > Thanks! > Bit -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Threading Questions
On Monday, 28 September 2015 at 11:47:38 UTC, Russel Winder wrote: I hadn't answered as I do not have answers to the questions you ask. My reason: people should not be doing their codes using these low-level shared memory techniques. Data parallel things should be using the std.parallelism module. Dataflow-style things should be using spawn and channels – akin to the way you do things in Go. So to give you an answer I would go back a stage, forget threads, mutexes, synchronized, etc. and ask what do you want you workers to do? If they are to do something and return a result then spawn and channel is exactly the right abstraction to use. Think "farmer–worker", the farmer spawns the workers and then collects their results. No shared memory anywyere – at least not mutable. https://www.youtube.com/watch?v=S7pGs7JU7eM Bit
Re: Threading Questions
On Tue, 2015-09-29 at 03:05 +, bitwise via Digitalmars-d-learn wrote: > On Monday, 28 September 2015 at 11:47:38 UTC, Russel Winder wrote: > > I hadn't answered as I do not have answers to the questions you > > ask. My reason: people should not be doing their codes using > > these low-level shared memory techniques. Data parallel things > > should be using the std.parallelism module. Dataflow-style > > things should be using spawn and channels – akin to the way you > > do things in Go. > > > > So to give you an answer I would go back a stage, forget > > threads, mutexes, synchronized, etc. and ask what do you want > > you workers to do? If they are to do something and return a > > result then spawn and channel is exactly the right abstraction > > to use. Think "farmer–worker", the farmer spawns the workers > > and then collects their results. No shared memory anywyere – at > > least not mutable. > > https://www.youtube.com/watch?v=S7pGs7JU7eM > > Bit What's the tl;dr as text, I very, very rarely watch videos. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Threading Questions
On 9/25/15 11:19 AM, bitwise wrote: Hey, I've got a few questions if anybody's got a minute. I'm trying to wrap my head around the threading situation in D. So far, things seem to be working as expected, but I want to verify my solutions. 1) Are the following two snippets exactly equivalent(not just in observable behaviour)? a) Mutex mut; mut.lock(); scope(exit) mut.unlock(); b) Mutex mut; synchronized(mut) { } Will 'synchronized' call 'lock' on the Mutex, or do something else(possibly related to the interface Object.Monitor)? Yes. A mutex object has it's internal lock as its monitor. 2) Phobos has 'Condition' which takes a Mutex in the constructor. The documentation doesn't exactly specify this, but should I assume it works the same as std::condition_variable in C++? I am not sure about std::condition_variable. core.sync.condition works like a standard condition (https://en.wikipedia.org/wiki/Monitor_%28synchronization%29) For example, is this correct? Mutex mut; Condition cond = new Condition(mut); // mut must be locked before calling Condition.wait synchronized(mut) // depends on answer to (1) { // wait() unlocks the mutex and enters wait state // wait() must re-acquire the mutex before returning when cond is signalled cond.wait(); } Yes, I believe it is. 3) Why do I have to pass a "Mutex" to "Condition"? Why can't I just pass an "Object"? An object that implements the Monitor interface may not actually be a mutex. For example, a pthread_cond_t requires a pthread_mutex_t to operate properly. If you passed it anything that can act like a lock, it won't work. So the Condition needs to know that it has an actual Mutex, not just any lock-like object. I think I advocated in the past to Sean that Condition should provide a default ctor that just constructs a mutex, but it doesn't look like that was done. 4) Will D's Condition ever experience spurious wakeups? What do you mean by "spurious"? If you notify a condition, anything that is waiting on it can be woken up. Since the condition itself is user defined, there is no way for the actual Condition to verify you will only be woken up when it is satisfied. In terms of whether a condition could be woken when notify *isn't* called, I suppose it's possible (perhaps interrupted by a signal?). But I don't know why it would matter -- per above you should already be checking the condition while within the lock. I think there are cases with multiple threads where you can potentially wake up the thread waiting on a condition AFTER the condition was already reset by another. 5) Why doesn't D's Condition.wait take a predicate? I assume this is because the answer to (4) is no. The actual "condition" that you are waiting on is up to you to check/define. 6) Does 'shared' actually have any effect on non-global variables beside the syntactic regulations? I believe shared doesn't alter code generation at all. It only prevents certain things and affects the type. I know that all global variables are TLS unless explicitly marked as 'shared', but someone once told me something about 'shared' affecting member variables in that accessing them from a separate thread would return T.init instead of the actual value... or something like that. This seems to be wrong(thankfully). No, this isn't true. For example, I have created this simple Worker class which seems to work fine without a 'shared' keyword in sight(thankfully). I'm wondering though, if there would be any unexpected consequences of doing things this way. http://dpaste.com/2ZG2QZV Some errors: 1. When calling notifyAll, you should ALWAYS have the mutex locked. 2. Since the mutex is protecting _run, it should only be checked/modified with the lock held. 3. After you have been woken up, you should check that the condition is satisfied. 4. Technically, you shouldn't access member variables that are GC allocated from a dtor. I know it's a struct, but structs can be GC allocated as well. I would replace your if(tasks.empty) with while(tasks.empty && _run) to fix issue 3. -Steve
Re: Threading Questions
Am Tue, 29 Sep 2015 15:10:58 -0400 schrieb Steven Schveighoffer : > > > 3) Why do I have to pass a "Mutex" to "Condition"? Why can't I just > > pass an "Object"? > > An object that implements the Monitor interface may not actually be a > mutex. For example, a pthread_cond_t requires a pthread_mutex_t to > operate properly. If you passed it anything that can act like a lock, > it won't work. So the Condition needs to know that it has an actual > Mutex, not just any lock-like object. > > I think I advocated in the past to Sean that Condition should provide > a default ctor that just constructs a mutex, but it doesn't look like > that was done. > But you'll need access to the Mutex in user code as well. And often you use multiple Conditions with one Mutex so a Condition doesn't really own the Mutex. > > > > 4) Will D's Condition ever experience spurious wakeups? > > What do you mean by "spurious"? If you notify a condition, anything > that is waiting on it can be woken up. Since the condition itself is > user defined, there is no way for the actual Condition to verify you > will only be woken up when it is satisfied. > > In terms of whether a condition could be woken when notify *isn't* > called, I suppose it's possible (perhaps interrupted by a signal?). > But I don't know why it would matter -- per above you should already > be checking the condition while within the lock. Spurious wakeup is a common term when talking about posix conditions and it does indeed mean a wait() call can return without ever calling notify(): https://en.wikipedia.org/wiki/Spurious_wakeup http://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups And yes, this does happen for core.sync.condition as well. As a result you'll always have to check in a loop: synchronized(mutex) { while(some_flag_or_expression) { cond.wait(); } } - synchronized(mutex) { some_flag_or_expression = true; cond.notify(); } > > I think there are cases with multiple threads where you can > potentially wake up the thread waiting on a condition AFTER the > condition was already reset by another. > > > 5) Why doesn't D's Condition.wait take a predicate? I assume this is > > because the answer to (4) is no. > > The actual "condition" that you are waiting on is up to you to > check/define. > He probably means that you could pass an expression to wait and wait would do the looping / check internally. That's probably a nicer API but not implemented. > > 6) Does 'shared' actually have any effect on non-global variables > > beside the syntactic regulations? > > I believe shared doesn't alter code generation at all. It only > prevents certain things and affects the type. > It shouldn't. I think in GDC it does generate different code, but that's an implementation detail that needs to be fixed.
Re: Threading Questions
On 9/29/15 4:38 PM, Johannes Pfau wrote: Am Tue, 29 Sep 2015 15:10:58 -0400 schrieb Steven Schveighoffer : 3) Why do I have to pass a "Mutex" to "Condition"? Why can't I just pass an "Object"? An object that implements the Monitor interface may not actually be a mutex. For example, a pthread_cond_t requires a pthread_mutex_t to operate properly. If you passed it anything that can act like a lock, it won't work. So the Condition needs to know that it has an actual Mutex, not just any lock-like object. I think I advocated in the past to Sean that Condition should provide a default ctor that just constructs a mutex, but it doesn't look like that was done. But you'll need access to the Mutex in user code as well. synchronized(condition.mutex) And often you use multiple Conditions with one Mutex so a Condition doesn't really own the Mutex. It's just a different option. Often times, you have a condition variable, and a mutex variable. It's not super-important, you can always do: new Condition(new Mutex); 4) Will D's Condition ever experience spurious wakeups? What do you mean by "spurious"? If you notify a condition, anything that is waiting on it can be woken up. Since the condition itself is user defined, there is no way for the actual Condition to verify you will only be woken up when it is satisfied. In terms of whether a condition could be woken when notify *isn't* called, I suppose it's possible (perhaps interrupted by a signal?). But I don't know why it would matter -- per above you should already be checking the condition while within the lock. Spurious wakeup is a common term when talking about posix conditions and it does indeed mean a wait() call can return without ever calling notify(): https://en.wikipedia.org/wiki/Spurious_wakeup http://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups OK thanks. 5) Why doesn't D's Condition.wait take a predicate? I assume this is because the answer to (4) is no. The actual "condition" that you are waiting on is up to you to check/define. He probably means that you could pass an expression to wait and wait would do the looping / check internally. That's probably a nicer API but not implemented. yeah, that could probably be done. One thing to note is that these classes are from ages ago (probably close to 10 years). New API suggestions may be allowed. I just wanted to stress that there isn't some sort of built-in condition predicate (like a boolean). -Steve
Re: Threading Questions
On Tuesday, September 29, 2015 22:38:42 Johannes Pfau via Digitalmars-d-learn wrote: > Am Tue, 29 Sep 2015 15:10:58 -0400 > schrieb Steven Schveighoffer : > > > > > > 3) Why do I have to pass a "Mutex" to "Condition"? Why can't I just > > > pass an "Object"? > > > > An object that implements the Monitor interface may not actually be a > > mutex. For example, a pthread_cond_t requires a pthread_mutex_t to > > operate properly. If you passed it anything that can act like a lock, > > it won't work. So the Condition needs to know that it has an actual > > Mutex, not just any lock-like object. > > > > I think I advocated in the past to Sean that Condition should provide > > a default ctor that just constructs a mutex, but it doesn't look like > > that was done. > > > > But you'll need access to the Mutex in user code as well. And often you > use multiple Conditions with one Mutex so a Condition doesn't really > own the Mutex. > > > > > > > 4) Will D's Condition ever experience spurious wakeups? > > > > What do you mean by "spurious"? If you notify a condition, anything > > that is waiting on it can be woken up. Since the condition itself is > > user defined, there is no way for the actual Condition to verify you > > will only be woken up when it is satisfied. > > > > In terms of whether a condition could be woken when notify *isn't* > > called, I suppose it's possible (perhaps interrupted by a signal?). > > But I don't know why it would matter -- per above you should already > > be checking the condition while within the lock. > > Spurious wakeup is a common term when talking about posix conditions > and it does indeed mean a wait() call can return without ever calling > notify(): > https://en.wikipedia.org/wiki/Spurious_wakeup > http://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups > > And yes, this does happen for core.sync.condition as well. As a result > you'll always have to check in a loop: > > synchronized(mutex) > { > while(some_flag_or_expression) > { > cond.wait(); > } > } > > - > synchronized(mutex) > { > some_flag_or_expression = true; > cond.notify(); > } What I took from the answers to that SO question was that in general, it really doesn't matter whether a condition variable has spurious wakeups. You're going to have to check that the associated bool is true when you wake up anyway. Maybe without spurious wakeups, it wouldn't be required if only one thread was waiting for the signal, but you'd almost certainly still need an associated bool in case it becomes true prior to waiting. In addition, if you want to avoid locking up your program, it's ferquently the case that you want a timed wait so that you can check whether the program is trying to exit (or at least that the thread in question is being terminated), and you'd need a separate bool in that case as well so that you can check whether the condition has actually been signaled. So, ultimately, while spurious wakeups do seem wrong from a correctness perspective, when you look at what a condition variable needs to do, it usually doesn't matter that spurious wakeups exist, and a correctly used condition variable will just handle spurious wakeups as a side effect of how it's used. - Jonathan M Davis
Re: Threading Questions
On Friday, 25 September 2015 at 15:19:27 UTC, bitwise wrote: I know that all global variables are TLS unless explicitly marked as 'shared', but someone once told me something about 'shared' affecting member variables in that accessing them from a separate thread would return T.init instead of the actual value... or something like that. This seems to be wrong(thankfully). T.init is returned for TLS variable when accessed from a thread for which it wasn't initialized.
Re: Threading Questions
On Tuesday, 29 September 2015 at 19:10:58 UTC, Steven Schveighoffer wrote: An object that implements the Monitor interface may not actually be a mutex. For example, a pthread_cond_t requires a pthread_mutex_t to operate properly. Right! I feel like I should have caught the fact that ConditionVariable still has to use pthread_cond_t under the hood, and adopts all of it's behaviour and requirements as a result. 4. Technically, you shouldn't access member variables that are GC allocated from a dtor. I know it's a struct, but structs can be GC allocated as well. Right forgot about that. GC's are really beginning to get on my nerves.. IMO, RAII for GC is a horrible tradeoff. I'm still not sure I would like Rust, but their memory model is making it a very enticing proposition. I'm almost at the point where I just don't care how much convenience, or familiarity D can offer in other areas.. Its starting to seem like none of it is worth it with a GC-based memory model standing in the way. Maybe this is an exageration...D has a lot of great features..but it's the net benefit that will ultimately determine whether or not people use D. I use C#(garbage collected) for making apps/games, and while, _in_theory_, the GC is supposed to protect you from leaks, memory is not the only thing that can leak. Threads need to be stopped, graphics resources need to be released, etc.. So when I can't rely on RAII to free these things, I need to free them explicitly, which basically puts me right back where I started. Anyways, I realize this will probably be buried 3 pages deep in D-Learn by Monday, but at least I feel better :) Bit
Re: Threading Questions
On Tuesday, 29 September 2015 at 23:20:31 UTC, Steven Schveighoffer wrote: yeah, that could probably be done. One thing to note is that these classes are from ages ago (probably close to 10 years). New API suggestions may be allowed. -Steve I'm still thinking about my last rant, here... So by new API, do you mean just adding a couple of new functions, or rewriting a new Condition class(as is the plan for streams)? Since D is moving towards a phobos with no GC, what will happen to things that are classes like Condition and Mutex? If DIP74 were implemented, Condition and Mutex could be made ref counted, but DIP74 seems like something that will be very complicated, and may not happen for a long time. So the only other alternative is to make it a struct, but for a Mutex, that would prevent you from doing this: Mutex m = new Mutex(); synchronized(m) { } I also don't mind the way that the current streams are made up of a class hierarchy. Although inheritance is overused sometimes, I don't think it's bad. But, if I'm correct about the current trend in D, it seems any new stream stuff will end up getting flattened into some template/struct solution. Any comments on this? Thanks, Bit
Re: Threading Questions
On Wednesday, 30 September 2015 at 10:32:01 UTC, Jonathan M Davis wrote: On Tuesday, September 29, 2015 22:38:42 Johannes Pfau via Digitalmars-d-learn wrote: [...] What I took from the answers to that SO question was that in general, it really doesn't matter whether a condition variable has spurious wakeups. You're going to have to check that the associated bool is true when you wake up anyway. Maybe without spurious wakeups, it wouldn't be required if only one thread was waiting for the signal, but you'd almost certainly still need an associated bool in case it becomes true prior to waiting. In addition, if you want to avoid locking up your program, it's ferquently the case that you want a timed wait so that you can check whether the program is trying to exit (or at least that the thread in question is being terminated), and you'd need a separate bool in that case as well so that you can check whether the condition has actually been signaled. So, ultimately, while spurious wakeups do seem wrong from a correctness perspective, when you look at what a condition variable needs to do, it usually doesn't matter that spurious wakeups exist, and a correctly used condition variable will just handle spurious wakeups as a side effect of how it's used. - Jonathan M Davis Yea, I guess you're right. The class in the example I posted was a crude reproduction of something I'm using right now in another project: http://codepad.org/M4fVyiXf I don't think it would make a difference whether it woke up randomly or not. I've been using this code regularly with no problems. Bit
Re: Threading Questions
On Sunday, October 04, 2015 14:42:48 bitwise via Digitalmars-d-learn wrote: > Since D is moving towards a phobos with no GC, what will happen > to things that are classes like Condition and Mutex? Phobos and druntime will always use the GC for some things, and some things just plain need classes. Rather, we're trying to make it so that Phobos does not use the GC when it doesn't need to use the GC as well reduce how much the GC is required for stuff like string processing where lazy ranges can be used instead in many cases. As for Condition and Mutex specifically, I don't know whey they were ever classes except perhaps to take advantage of the monitor in Object. Maybe they'll get changed to structs, maybe they won't, but most D code is thread-local, and most of the code that isn't is going to use message passing, which means that explicit mutexes and conditions are unnecessary. So, most code won't be impacted regardless of what we do with Condition and Mutex. Regardless, I doubt that anything will be done with Condition or Mutex until shared is revisted, which is supposed to happen sometime soon but hasn't happened yet. What happens with shared could completely change how Condition and Mutex are handled (e.g. they don't support shared directly even though they should probably have most of their members marked with shared, because Sean Kelly didn't want to be doing anything with shared that he'd have to change later). - Jonathan M Davis
Re: Threading Questions
On Monday, 5 October 2015 at 00:23:21 UTC, Jonathan M Davis wrote: On Sunday, October 04, 2015 14:42:48 bitwise via Digitalmars-d-learn wrote: Since D is moving towards a phobos with no GC, what will happen to things that are classes like Condition and Mutex? Phobos and druntime will always use the GC for some things, and some things just plain need classes. Rather, we're trying to make it so that Phobos does not use the GC when it doesn't need to use the GC as well reduce how much the GC is required for stuff like string processing where lazy ranges can be used instead in many cases. I was under the impression that the idea was to _completely_ eliminate the GC. It says in Andre's 2015H1 vision statement: "We aim to make the standard library usable in its entirety without a garbage collector." I understand the allocation/freeing of memory is expensive, but I thought the actual sweep of the GC was a problem too, and that disabling the GC to avoid the sweep was the plan for some people. I don't know how long D's GC takes to sweep, but even a 5ms pause would be unacceptable for a performance intensive game. I guess if you use @nogc properly though, you could still safely turn off the GC, right? As for Condition and Mutex specifically, I don't know whey they were ever classes except perhaps to take advantage of the monitor in Object. Maybe they'll get changed to structs, maybe they won't, but most D code is thread-local, and most of the code that isn't is going to use message passing, which means that explicit mutexes and conditions are unnecessary. So, most code won't be impacted regardless of what we do with Condition and Mutex. You may be right. I wrote a simple download manager in D using message passing. It was a little awkward at first, but in general, the spawn/send/receive API seems very intuitive. It feels awkward because the data you're working with is out of reach, but I guess it's safer that way. Regardless, I doubt that anything will be done with Condition or Mutex until shared is revisted, which is supposed to happen sometime soon but hasn't happened yet. What happens with shared could completely change how Condition and Mutex are handled (e.g. they don't support shared directly even though they should probably have most of their members marked with shared, because Sean Kelly didn't want to be doing anything with shared that he'd have to change later). - Jonathan M Davis I'm not sure what's going to be done with shared, but I do think it's annoying that you can't do this: shared Array!int numbers; someThread... { numbers.clear(); // 'clear' is not shared } So this means that on top of the already ridiculous number of attributes D has, now you have to mark everything as shared too =/ Bit
Re: Threading Questions
On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote: You may be right. I wrote a simple download manager in D using message passing. It was a little awkward at first, but in general, the spawn/send/receive API seems very intuitive. It feels awkward because the data you're working with is out of reach, but I guess it's safer that way. Any possibility of a blog post on your experience of doing so ? ;) [I should start writing some directly, but for time being, until I have my blog up and running again, I write from time to time on Quora]. A few minutes of writing now and then can have a remarkably big impact as well as clarifying your own thoughts, and the time invested is amply repaid, even viewed from a narrowly self-interested perspective. I had same experience with learning message passing. Feels like learning to eat with chopsticks in the beginning, but soon enough it feels much more civilised when it's the right tool for the job.
Re: Threading Questions
On 10/5/15 1:40 PM, bitwise wrote: On Monday, 5 October 2015 at 00:23:21 UTC, Jonathan M Davis wrote: On Sunday, October 04, 2015 14:42:48 bitwise via Digitalmars-d-learn wrote: Since D is moving towards a phobos with no GC, what will happen to things that are classes like Condition and Mutex? Phobos and druntime will always use the GC for some things, and some things just plain need classes. Rather, we're trying to make it so that Phobos does not use the GC when it doesn't need to use the GC as well reduce how much the GC is required for stuff like string processing where lazy ranges can be used instead in many cases. I was under the impression that the idea was to _completely_ eliminate the GC. It says in Andre's 2015H1 vision statement: "We aim to make the standard library usable in its entirety without a garbage collector." No, the plan is to allow the user to choose how he wants to allocate. Many pieces of phobos make the assumption that the GC is fair game. I think the plan is to make those pieces instead allocate on the stack and provide a mechanism to move that allocation to the GC (Walter's Dconf talk was about this), or accept an allocator to use as a mechanism for allocating memory. -Steve
Re: Threading Questions
On Monday, 5 October 2015 at 20:18:18 UTC, Laeeth Isharc wrote: On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote: You may be right. I wrote a simple download manager in D using message passing. It was a little awkward at first, but in general, the spawn/send/receive API seems very intuitive. It feels awkward because the data you're working with is out of reach, but I guess it's safer that way. Any possibility of a blog post on your experience of doing so ? ;) [I should start writing some directly, but for time being, until I have my blog up and running again, I write from time to time on Quora]. A few minutes of writing now and then can have a remarkably big impact as well as clarifying your own thoughts, and the time invested is amply repaid, even viewed from a narrowly self-interested perspective. Unfortunately, my time is limited right now. I do have another project, which I've decided will either be finished or discarded by the dawn of 2016. So in the near future, I should have more time for other things. I had same experience with learning message passing. Feels like learning to eat with chopsticks in the beginning, but soon enough it feels much more civilised when it's the right tool for the job. I like the way my Worker class works because when I don't need the thread anymore, I can simply discard the object that represents the thread. As long as the Worker object is higher up on the stack than anything it's working on, all is well, and the concept of spawn/join is not visible while programming. This works out ok, because while the jobs I'm doing are slow enough to make a UI thread lag, they aren't long-running enough to where waiting for the Worker's thread to join in the destructor becomes a problem. There may be a small lag as the Worker's destructor waits for the last job to finish and the thread to join, but it's only happens once in the lifetime of the worker, so it's not a big deal. If care is not taken, the above could be subject to these problems: 1) shared memory corruption 2) worker accessing dead memory if it's placed on the stack below what it's working on 3) queueing a long running task could freeze the program on ~Worker() If you're moving or copying data into a thread, then returning the result(which can be ignored) I think most of the above can be solved. It's still a bit foreign to me though, and C++ has no such construct yet afaik. I read a bit about std::future and so on, but I'm not sure if they're standard yet. The biggest blocker though, is that the project I'm using that Worker class in is a Unity3D plugin. They only very recently updated their iOS libs to allow libc++ > 98 Bit
Re: Threading Questions
On Sunday, 4 October 2015 at 04:24:55 UTC, bitwise wrote: I use C#(garbage collected) for making apps/games, and while, _in_theory_, the GC is supposed to protect you from leaks, memory is not the only thing that can leak. Threads need to be stopped, graphics resources need to be released, etc. XNA doesn't manage graphics resources? On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote: I'm not sure what's going to be done with shared, but I do think it's annoying that you can't do this: shared Array!int numbers; someThread... { numbers.clear(); // 'clear' is not shared } So this means that on top of the already ridiculous number of attributes D has, now you have to mark everything as shared too =/ That's illegal in other languages too except that they allow you to do it. If you want concurrent collections, you must code them separately: https://msdn.microsoft.com/en-us/library/system.collections.concurrent%28v=vs.110%29.aspx
Re: Threading Questions
On Wednesday, 7 October 2015 at 09:09:36 UTC, Kagamin wrote: On Sunday, 4 October 2015 at 04:24:55 UTC, bitwise wrote: I use C#(garbage collected) for making apps/games, and while, _in_theory_, the GC is supposed to protect you from leaks, memory is not the only thing that can leak. Threads need to be stopped, graphics resources need to be released, etc. XNA doesn't manage graphics resources? On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote: I'm not sure what's going to be done with shared, but I do think it's annoying that you can't do this: shared Array!int numbers; someThread... { numbers.clear(); // 'clear' is not shared } So this means that on top of the already ridiculous number of attributes D has, now you have to mark everything as shared too =/ That's illegal in other languages too except that they allow you to do it. If you want concurrent collections, you must code them separately: https://msdn.microsoft.com/en-us/library/system.collections.concurrent%28v=vs.110%29.aspx I'm not sure what you mean by illegal. AFAIK 'shared' is unique to D. As far as simply locking and then accessing a global variable(class static member) in C#, there is no problem doing that from multiple threads. If you have System.Collections.Generic.List(T) static class member, there is nothing wrong with using it from multiple threads like this: class Foo { static List numbers = new List(); void bar() { new Thread(()=>{ lock(numbers) { numbers.Add(1); }).Start(); } } Bit
Re: Threading Questions
On Thursday, 8 October 2015 at 02:31:24 UTC, bitwise wrote: If you have System.Collections.Generic.List(T) static class member, there is nothing wrong with using it from multiple threads like this: The equivalent of your D example would be class Foo { static List numbers = new List(); void bar() { new Thread(()=>{ numbers.Add(1); }).Start(); } }
Re: Threading Questions
On Thursday, 8 October 2015 at 10:11:38 UTC, Kagamin wrote: On Thursday, 8 October 2015 at 02:31:24 UTC, bitwise wrote: If you have System.Collections.Generic.List(T) static class member, there is nothing wrong with using it from multiple threads like this: The equivalent of your D example would be class Foo { static List numbers = new List(); void bar() { new Thread(()=>{ numbers.Add(1); }).Start(); } } That still doesn't explain what you mean about it being illegal in other languages or why you brought up C# in the first place. Bit
Re: Threading Questions
On Thursday, 8 October 2015 at 13:44:46 UTC, bitwise wrote: That still doesn't explain what you mean about it being illegal in other languages or why you brought up C# in the first place. Illegal means the resulting program behaves incorrectly, potentially leading to silent failures and data corruption. C# is a language that allows such bugs, and D disallows them - treats such code as invalid and rejects.
Re: Threading Questions
On Thursday, 8 October 2015 at 20:42:46 UTC, Kagamin wrote: On Thursday, 8 October 2015 at 13:44:46 UTC, bitwise wrote: That still doesn't explain what you mean about it being illegal in other languages or why you brought up C# in the first place. Illegal means the resulting program behaves incorrectly, potentially leading to silent failures and data corruption. C# is a language that allows such bugs, and D disallows them - treats such code as invalid and rejects. Ah, I see. I thought you meant illegal meant it won't compile. Wouldn't it be more correct to say that it's undefined behaviour? Bit
Re: Threading Questions
On Friday, 9 October 2015 at 04:04:42 UTC, bitwise wrote: Ah, I see. I thought you meant illegal meant it won't compile. Wouldn't it be more correct to say that it's undefined behaviour? I's probably not as undefined as in C case, i.e. it doesn't break safety guarantees, only the application's high-level business logic gets confused by data races.