So, you suggest I should build a commercial desktop application (for processing print-industry files and presenting them in a UI) in such a way that it spawns multiple processes and communicates with them via the filesystem or IPC APIs?
Why would I want to go to that level of complexity in an uncontrollable environment (i.e. a consumer desktop computer) when I can just use NSOperation, boost::thread, and boost::mutex to build a single-process solution that shares data in a normal way between tasks? James Gregurich Engineering Manager Markzware On Apr 29, 2009, at 11:23 PM, Roger Binns wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > James Gregurich wrote: >> Given the industry is going multicore and 16-core macintoshes for >> your >> grand-mother are just a few years away, I recommend you rethink your >> position on the use of threading. > > Threading is the worst solution to many cpu/core and large memory. > Having the same memory addressed (which is what threading does) across > multiple concurrently executing cpus/cores causes cache thrashing, > memory contention, frequent use of memory barriers for synchronization > (which also slows things down) and as memory becomes attached to > individual cpus leads to access being over hypertransport/csi. > > Far better is using multiple processes which don't have those > issues. A > good example application to study is Google Chrome which uses multiple > processes prolifically - each tab is a separate process, as well as > the > various plugins, languages etc. Each process can be appropriately > locked down using the principle of least privilege. If you use > threads > then typically they all have permission to do anything the process > could do. > > (Also the multi-process approach is way easier to test, record/replay > and is more deterministic) > > Erlang is also worth studying. It only has single threaded processes > (although the processes are lighter weight than operating system > processes). > >> NSOperation is a major part of that effort. > > If the "single encapsulated task" doesn't go around concurrently > touching bits of memory then it could be shunted to a separate process > anyway. > > The danger from threads is not the threads themselves, but the > concurrency. It is virtually impossible to prove that a threaded > process does the concurrency correctly under all circumstances. If > you > eliminate the concurrency then you can use multiple processes, and can > usually even make it scale over multiple machines! > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkn5Q9MACgkQmOOfHg372QSS/QCfSje/tyX0hmidHyubVKqrXlHt > Sq0AoKEbmcwx/fmAFtcVeMjbcUgN8dr3 > =8lUQ > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
