[go-nuts] Re: no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!
ok,i will try,thanks. 在 2017年7月27日星期四 UTC+8下午8:33:24，JuciÊ Andrade写道： > > 3702, I think you need to learn some fundamental concepts to better > understand the problem at hand. > > > Processors have more than one core. That means we have several threads > running simultaneously. To let more than one thread access the same memory > region is a bad idea. If your program simply crashes consider yourself a > lucky guy. There are other subtle problems that can be dangerous and > difficult to spot. > > > So, the programmer must find a way to avoid those simultaneous access. A > popular way is by using some synchronization object, i.e. a mutex. Before > any access to the shared state, a thread must lock the mutex, releasing it > when the access is done. For small programs, it works. However, as your > program grows, that approach can get complicated in insidious ways. > > > Go offers mutex, as several other languages do, but it offers a much > better device: channels. There are dozens of ways to use channels, but I > will give you just an example. > > > Divide your program so that only one goroutine can access the memory area. > Let’s call this goroutine the “data owner”. That way you eliminate the > shared state problem at once, because there will be no shared state, at all. > > > When some other goroutine needs to read or change that state, it ASKs the > data owner to do the access on its behalf. How? By sending a request thru a > channel, that’s how. The data owner process those requests, performing the > required actions. > > > Learn to use channels, 3702. After a little practice, your programs will > run fast and safely. As an additional benefit the architecture will be > solid, easy to change when the need arises. > > On Thursday, July 27, 2017 at 7:28:39 AM UTC-3, 3702...@qq.com wrote: >> >> o yea,thanks.it's a good way to improve the performance of my >> program.but will it solve the problem,crashing? >> >> 在 2017年7月27日星期四 UTC+8上午12:26:36，JuciÊ Andrade写道： >>> >>> I mean bytes.Buffer. >>> >>> On Wednesday, July 26, 2017 at 8:08:13 AM UTC-3, JuciÊ Andrade wrote: Dear friend 3702, while you are at it, please change that string appending strategy. Use a bufio.Buffer instead. It's way faster. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!
3702, I think you need to learn some fundamental concepts to better understand the problem at hand. Processors have more than one core. That means we have several threads running simultaneously. To let more than one thread access the same memory region is a bad idea. If your program simply crashes consider yourself a lucky guy. There are other subtle problems that can be dangerous and difficult to spot. So, the programmer must find a way to avoid those simultaneous access. A popular way is by using some synchronization object, i.e. a mutex. Before any access to the shared state, a thread must lock the mutex, releasing it when the access is done. For small programs, it works. However, as your program grows, that approach can get complicated in insidious ways. Go offers mutex, as several other languages do, but it offers a much better device: channels. There are dozens of ways to use channels, but I will give you just an example. Divide your program so that only one goroutine can access the memory area. Let’s call this goroutine the “data owner”. That way you eliminate the shared state problem at once, because there will be no shared state, at all. When some other goroutine needs to read or change that state, it ASKs the data owner to do the access on its behalf. How? By sending a request thru a channel, that’s how. The data owner process those requests, performing the required actions. Learn to use channels, 3702. After a little practice, your programs will run fast and safely. As an additional benefit the architecture will be solid, easy to change when the need arises. On Thursday, July 27, 2017 at 7:28:39 AM UTC-3, 3702...@qq.com wrote: > > o yea,thanks.it's a good way to improve the performance of my program.but > will it solve the problem,crashing? > > 在 2017年7月27日星期四 UTC+8上午12:26:36，JuciÊ Andrade写道： >> >> I mean bytes.Buffer. >> >> On Wednesday, July 26, 2017 at 8:08:13 AM UTC-3, JuciÊ Andrade wrote: >>> >>> Dear friend 3702, while you are at it, please change that string >>> appending strategy. Use a bufio.Buffer instead. It's way faster. >>> >>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!
o yea,thanks.it's a good way to improve the performance of my program.but will it solve the problem,crashing? 在 2017年7月27日星期四 UTC+8上午12:26:36，JuciÊ Andrade写道： > > I mean bytes.Buffer. > > On Wednesday, July 26, 2017 at 8:08:13 AM UTC-3, JuciÊ Andrade wrote: >> >> Dear friend 3702, while you are at it, please change that string >> appending strategy. Use a bufio.Buffer instead. It's way faster. >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!
I mean bytes.Buffer. On Wednesday, July 26, 2017 at 8:08:13 AM UTC-3, JuciÊ Andrade wrote: > > Dear friend 3702, while you are at it, please change that string appending > strategy. Use a bufio.Buffer instead. It's way faster. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: no.something seem like impossible,but it happens!!!!【 string 】causes the crash !!!!!!!!!!!!!!
Dear friend 3702, while you are at it, please change that string appending
strategy. Use a bufio.Buffer instead. It's way faster.
> type bad.go
package main
import (
"fmt"
"time"
)
func main() {
var s string
begin := time.Now()
for i := 0; i != 10; i++ {
s = s + "lalalala"
}
fmt.Printf("len = %d, %d ns\n", len(s),
time.Now().UnixNano()-begin.UnixNano())
}
> bad.exe
len = 80, 3573571400 ns
> bad.exe
len = 80, 3564547900 ns
> bad.exe
len = 80, 3657745100 ns
> type good.go
package main
import (
"bytes"
"fmt"
"io"
"time"
)
func main() {
var b bytes.Buffer
begin := time.Now()
for i := 0; i != 10; i++ {
io.WriteString(, "lalalala")
}
s := b.String()
fmt.Printf("len = %d, %d secs\n", len(s),
time.Now().UnixNano()-begin.UnixNano())
}
> good.exe
len = 80, 2991600 secs
> good.exe
len = 80, 4002600 secs
> good.exe
len = 80, 3001800 secs
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
