Thread synchronization with in the same address space

[teclis High Elf]

So L4Re is POSIX compliant?

On Fri, Oct 10, 2014 at 12:16 PM, Björn Döbel <doebel at os.inf.tu-dresden.de>
wrote:

>
>
> Am 10.10.2014 um 18:00 schrieb teclis High Elf:
>
>> I have two threads running in the same server. On thread handles
>> incoming ipc messages from the clients in different address spaces and
>> the other thread does the work. The thread handling the incoming ipc
>> needs to pass an integer value to the worker thread. Could I synchronize
>> them using
>>
>> int l4util_cmpxchg32
>> <https://os.inf.tu-dresden.de/L4Re/doc/group__l4util__atomic.html#
>> gacb4a5e47fea67cc4c61b488fc374df62>
>> (volatile l4_uint32_t
>> <https://os.inf.tu-dresden.de/L4Re/doc/group__l4__basic__types.html#
>> gac1d09f3e382e711b776931f10e6e1e5a>
>> *dest, l4_uint32_t
>> <https://os.inf.tu-dresden.de/L4Re/doc/group__l4__basic__types.html#
>> gac1d09f3e382e711b776931f10e6e1e5a>
>> cmp_val, l4_uint32_t
>> <https://os.inf.tu-dresden.de/L4Re/doc/group__l4__basic__types.html#
>> gac1d09f3e382e711b776931f10e6e1e5a>
>> new_val)
>>
>> the worker thread could then check the value of dest to get the integer.
>> Would the worker thread need to use an atomic read function when it
>> reads the value of dest and if so which function would the worker thread
>> use for the atomic read?
>>
>
> In your scenario, I would think of it like this:
>
> int data = -1; // global variable, set to invalid value
>
> server_thread()
> {
>    int val = receive_message();
>    data = some_processing(val);
> }
>
> worker_thread()
> {
>     while (data == -1) // spin until data is valid
>       ;
>     /* Use data here */
> }
>
> I don't see the need for an atomic cmpxchg() in your specific case.
> Actually I would however suggest you use a pthread_mutex or a
> pthread_cond_var to synchronize your threads (or even IPC between the
> two...).
>
> Bjoern
>
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20141010/3f40d160/attachment.htm>