Hello; On Thu, Mar 23, 2023 at 11:48 AM Bob Weeks <bob.we...@btinternet.com.invalid> wrote: > > I created a little test module to just increment a value in this code > block each time I called the page and printout the next time it passed. > > ap_log_error(APLOG_MARK, APLOG_INFO,0,r->server,"Config = > %ld",(long)cfg->Data); > cfg->Data++; > return OK; > > > [Thu Mar 23 09:34:22.779569 2023] [btest:info] [pid 26649] Config = 4 > [Thu Mar 23 09:34:40.193054 2023] [btest:info] [pid 26647] Config = 5 > [Thu Mar 23 09:34:40.193422 2023] [btest:info] [pid 26647] Config = 6 > [Thu Mar 23 09:34:40.203726 2023] [btest:info] [pid 26647] Config = 7 > [Thu Mar 23 09:34:40.206444 2023] [btest:info] [pid 26662] Config = 9 > [Thu Mar 23 09:34:40.206663 2023] [btest:info] [pid 26651] Config = 27 > > Thread 26662 and 26651 still had inconsistent data. > > Is there a way of sharing data between threads with out creating a > semaphore
It depends on the size of your data, if it fits in a long as in your example you can use the apr_atomic API (32 or 64 bits). So something like apr_atomic_inc32(&cfg->Data) or apr_atomic_inc64(&cfg->Data) depending on whether the Data is an apr_uint32_t or an apr_uint64_t respectively. If your data is above 64bit, you need a mutex (apr_global_mutex_t for a memory shared between processes or apr_thread_mutex_t it's shared between threads in the same process). In any case if multiple readers/writers access your Data concurrently, the access should be atomic (be it with CPU atomic primitives for sizeof(Data) <= 8, or with a mutex exclusive section for larger structs). Regards; Yann.
