[ale] Help with C project

[Pete Hardie]

That might be the problem - the pthread_cond_wait() call must be made from
the thread you wish to pause

What you might need to do is have some sort of stop flag (protected by a
mutex) that the scheduler thread will set when it wishes the worker thread
to stop, and the worker thread has a loop that checks that and if set,
calls pthread_cond_wait().  Or if the worker thread can determine the need
to stop by itself, it can do so.

Since (if I understand your project correctly) you want the worker thread
to run for a limited amount of time, you will need it to have some sort of
loop to allow it to check for the pause condition (either it check clock
time to stop at the end of its timeslice, or checks for the scheduler to
flag it as needing to pause)



On Sat, Jan 23, 2016 at 5:26 PM, Christopher Hagler <
haglerchristopher at gmail.com> wrote:

> It is being called from the scheduler thread
> On Jan 23, 2016 5:24 PM, "Pete Hardie" <pete.hardie at gmail.com> wrote:
>
>> Is process_stop() being called from the running thread, or from the
>> scheduler thread?
>>
>> On Sat, Jan 23, 2016 at 2:41 PM, Christopher Hagler <
>> haglerchristopher at gmail.com> wrote:
>>
>>> Thank you for the reply. When I create a process, I give each thread
>>> their own condition variable because I can control which threads are run. I
>>> have a function called process_create that in turn calls pthread_cond_init.
>>> From my understanding a call to pthread_cond_signal does not guarantee
>>> scheduling order. Threads are not scheduled in the order they call
>>> pthread_cond_wait. This is why I give each thread their own condition
>>> variable. The scheduler will call process_start that will call
>>> pthread_cond_signal on the process struct passed in as a parameter. All of
>>> that works correctly. However a call to process_stop which calls
>>> pthread_cond_wait does not seem to work. From what I have read, it all
>>> seems correct, but the threads continue to run.
>>> On Jan 23, 2016 12:40 PM, "Pete Hardie" <pete.hardie at gmail.com> wrote:
>>>
>>>> It's been a while since I use pthreads directly, but the modus operandi
>>>> of condition variables is that you declare one before the
>>>> threads that use it are started, and the threads that you want to wait
>>>> will call wait() to pause until the another thread signals a change,
>>>> and then you would check the condition variable value to see if it is
>>>> the desired value to proceed.
>>>>
>>>> On Sat, Jan 23, 2016 at 11:52 AM, Christopher Hagler <
>>>> haglerchristopher at gmail.com> wrote:
>>>>
>>>>> I am working on a home automation project written in C. It allows a
>>>>> user to automate daily task with open source hardware and software.
>>>>> However, since I am lacking experience with pthreads, I have run into a
>>>>> couple of issues that I cant seem to resolve. The intentions of the code
>>>>> where the issues reside are:
>>>>>
>>>>> The project allows drivers to be written as shared objects that, which
>>>>> in turn, will control a remote hardware device or devices with all
>>>>> communication happening through shared memory. The Scheduler module will
>>>>> take the shared object, and schedule it to run via process queues. Once the
>>>>> process, a struct containing the shared object and an abstraction for a
>>>>> pthread, runs for its time slot, the scheduler will stop the process and
>>>>> place it in another process queue. The whole idea was to simulate an
>>>>> operating system scheduler because potentially there could be a few hundred
>>>>> threads. This is where the first issue resides. I am having trouble putting
>>>>> the process to sleep. I have done some research on pthreads and supposedly
>>>>> this can be accomplished via pthread condition variables. This is the
>>>>> solution I have attempted, and apparently I have not implemented it
>>>>> correctly. It will start the process which will run, but when I try to put
>>>>> it to sleep, it keeps running.
>>>>>
>>>>> The second issue is when ever you run the program, it fails to link
>>>>> the shared object sometimes. However, if you have to quickly run the
>>>>> program back-to-back, it will start and run fine. I am not sure why this is
>>>>> happening. It could possibly be linked to my setup, but I am not sure. I am
>>>>> running Opensuse in Virtual Box.
>>>>>
>>>>> Any advice on these issues would be greatly appreciated. I also know
>>>>> there are a couple of people who have been wanting to learn C, and you are
>>>>> more than welcome to join the project if you want.
>>>>>
>>>>> The code base:
>>>>> https://github.com/haglerchristopher/automation/tree/development
>>>>>
>>>>> Thanks for the help.
>>>>>
>>>>> _______________________________________________
>>>>> Ale mailing list
>>>>> Ale at ale.org
>>>>> http://mail.ale.org/mailman/listinfo/ale
>>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>>> http://mail.ale.org/mailman/listinfo
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Pete Hardie
>>>> --------
>>>> Better Living Through Bitmaps
>>>>
>>>> _______________________________________________
>>>> Ale mailing list
>>>> Ale at ale.org
>>>> http://mail.ale.org/mailman/listinfo/ale
>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>> http://mail.ale.org/mailman/listinfo
>>>>
>>>>
>>> _______________________________________________
>>> Ale mailing list
>>> Ale at ale.org
>>> http://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>> http://mail.ale.org/mailman/listinfo
>>>
>>>
>>
>>
>> --
>> Pete Hardie
>> --------
>> Better Living Through Bitmaps
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
>>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>


-- 
Pete Hardie
--------
Better Living Through Bitmaps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20160123/2cde5653/attachment.html>